前言
在Ozone中，众所周知，它最开始设计仿照的原型即是S3语义的存储模式：基于volume, bucket, key三层的存储模型，底层的key是实际存储的对象文件。至于里面对于volume, bucket, key级别的API操作，基本也是实现了S3现有支持的API操作。不过Ozone作为同样Hadoop生态圈内的一个项目，它需要与现有别的系统框架能够很好地协调工作。因此，Ozone内部实现了Ozone FS的语义，意思是说，外部别的框架可以使用文件系统API的方式来使用Ozone。简单来说，就是client可以对Ozone调用执行createFile，mkdir， listFile等等这样文件系统的API操作。至于这个里面Ozone是如何做FS API和实际底层Ozone bucket， key的存储，那是另外的原理实现了。OK，本文笔者要聊的重点是这里提到的Ozone内部的S3语义和FS语义。
Ozone的S3语义和FS语义
光看标题的术语，可能很多人不太能够理解，这里笔者给出具体的例子来说明。
S3语义，就是仿照S3存储/volume/bucket/key级别的存储模式，其中这里的key名称是可以不带任何限制的，比如key里可以带有 … 和 / 这种特殊的字符。
比如说是S3语义下，用户可以存入一个比较偏的key名称如下：
Key名称：/dir1dir2//…//dir3///file1
全路径：/volume/bucket/dir1dir2//…//dir3///file1
但是在FS语义下，我们就要对key的名称做标准化处理了，因为“/”字符在FS语义里代表的是一个目录的意思了。FS语义的意思简单理解是Ozone在对外使用上能够用文件系统的结构组织方式来访问。
因此Ozone内部在启用FS语义后，它会做一件重要的事情：Key名称的标准化(normalize)处理。
这个normalize操作里，多余的“/”会被移除掉。这样的话，我们就会得到一个干净的合理的key name。比如上面的key将会变为如下：
/dir1/dir2/…/dir3/file1
但是FS语义和原有S3语义不仅仅只有这一个差别，FS语义要保证其执行的正确性，比如上面这个路径对应的是一个文件路径，在建这个文件之前，我们需要保证其前面的目录都必须存在。这个时候如果它不存在，那么实际上我们还得额外执行put key名称为/dir1/, /dir1/dir2/, /dir1/dir2/…/, /dir1/dir2/…/dir3/的操作，就是递归执行父目录的操作。
区别图如下：
| Operation | S3语义 | FS语义 |
|---|---|---|
| CreateKey(dir1/dir2/dir3/file1) in volume vol, bucket buck | /vol/buck/dir1/dir2/dir3/file1 | /vol/buck/dir1/, /vol/buck/dir1/dir2/, /vol/buck/dir1/dir2/dir3/, /vol/buck/dir1/dir2/dir3/file1 |
我们可以看到在同样创建一个新key的情况下，S3语义下需要往Ozone key表里插入1行key，而FS语义下就要创建出4个key来保证别的FS语义操作的正常执行。
Ozone S3语义和FS语义的联合使用
因为Ozone目前同时支持了S3语义和FS语义的实现，那么就会存在一种混合使用的场景：
- 用S3语义的进行key的写入，但是用FS语义进行数据读取
- 用FS语义进行数据写入，用S3语义进行读取
在上面两种情况中，第一种情况显然更加复杂一些。因为S3语义对于key名称没限制，而且只建一条key，这样如果直接用FS语义去找，显然大概率会报key找不到的错误。
因此对于这种特殊的使用场景，Ozone内部新增了一个配置ozone.om.enable.filesystem.paths来表明Ozone是否将会把key名称用FS语义的方式来读取。
<property>
<name>ozone.om.enable.filesystem.paths</name>
<tag>OZONE, OM</tag>
<value>false</value>
<description>If true, key names will be interpreted as file system paths.
"/" will be treated as a special character and paths will be normalized
and must follow Unix filesystem path naming conventions. This flag will
be helpful when objects created by S3G need to be accessed using OFS/O3Fs.
If false, it will fallback to default behavior of Key/MPU create
requests where key paths are not normalized and any intermediate
directories will not be created or any file checks happens to check
filesystem semantics.
</description>
</property>
如果这个配置被启用后，那么S3语义下操作的key会在原有执行步骤中多加2步：
- 1）进行key的标准化处理
- 2）进行额外parent key的创建，如果需要的话(例子如上所示)。
以上就是本文阐述主要内容了，相关详细内容可查阅引用链接处。
引用
[1].https://issues.apache.org/jira/browse/HDDS-4097 . S3/Ozone Filesystem inter-op