前言
之前笔者介绍过Ozone如何作为Hadoop兼容性文件系统供外部应用使用，就是我们所说的Ozone FileSystem。但是Ozone FileSystem在本质上并没有改变底层Key在Ozone中的存储形式，它只是做了一个从树型结构的路径到Ozone的volume，bucket，key的转化（详细文章可见此：Ozone FileSystem的内部原理实现分析）。那么我们是否能够以一种完全符合传统意义上的树型组织形式的命名空间，并且同时保持底层文件以Key对象的形式存储于Ozone之上呢？本文笔者来聊聊Ozone社区对此的一个方案设想，目前还在实现过程中。
Ozone FS Namespace综述
首先介绍什么叫做Ozone FS Namespace，Ozone FS Namespace的意思是我们在Ozone内部实现FileSystem命名空间的支持。在FS Namespace下，我们有目录以及文件的metadata信息以及他们之间的上下组织管理。
Ozone FS Namespace相比现有Ozone FileSystem的实现方式来说，有以下优劣势：
优势：实现了FileSystem本身的Namespace形式，灵活性更强，使得文件操作更加高效。现有Ozone FileSystem只是把外部路径进行了包装转化处理，它在进行目录级别操作时，采用的是前缀匹配遍历的方式做处理，这并不是一种高效的做法。
劣势：将Namespace形式引入Ozone可能引发潜在的Ozone的性能问题。因为FS Namespace的改动将会更新Ozone Manager内部对于metadata现有的处理方式。
Ozone FS Namespace的结构设计
下面我们来看具体Ozone FS Namespace的结构设计。在社区对此的设计中，它分出了2张表来分别存放目录和文件的metadata信息，在这里我们简称之为Directory Table和File Table。
比如路径名为“/a/b/c/d/1.txt”的文件，它在Ozone FS Namespace的信息保存格式为，4个entry项在Directory Table内，1个entry项在File Table内。
4个Directory Table项：a，b，c，d。
1个File Table项：1.txt。
光有上述独立的entry项还不够，我们还缺少其中的组织关系。Ozone在这里通过额外保存Prefix的属性来表示其所属的父目录信息，父目录信息用ID标识。
[parent unique-id]/[directory name] => [directory unique-id]
文件信息表示类似如上：
[parent unique-id]/[file name] => [OM KeyInfo]
以/a/b/c/d/1.txt为例，实际Directory Table，File Table的存储形式将如下所示：
Directory Table：
| Prefix | ID |
|---|---|
| / | 99 |
| 99/a | 100 |
| 100/b | 101 |
| 101/c | 102 |
File Table：
| Filename | Key Metadata |
|---|---|
| 102/1.txt | KeyInfo |
以上前缀存储的形式能带来明显的空间节省的开销，因为每个目录Entry项的父目录路径部分只需要用1个64位(8字节)的数字ID表示即可。比如在在文件名平均为32字节，总路径长度256字节的情况下，100w个文件要消耗到256GB(= 2^30 * 256Bytes)的空间。而在前缀模式下，我们还是只用32个字节存储的情况下，只需要用到32GB的空间即可，我们只要哪出其中的32字节的8个字节用来存储前缀ID即可。
不过上述存储方式会带来其他2方面的不足之处：
- 每次文件路径的插入操作会变成Directory Table，File Table表的多次插入操作，不过如果后续父目录都已经存在了，父目录的插入操作可以省略了，接近于单次插入操作。
- 文件信息的查找需要表的路径的逐级遍历。因为这里没有将目录项的全部记录在Table内，而是截断拆分存放，所以需要逐级往下寻找得到最终的文件目录信息。在namespace的查找性能效率上不如传统单一目录项存放方式。
但总体说来，上面所说的新FS Namespace的结构方式无非就是系统在空间和时间的trade off，空间用得省了，效率就要低一点点。
Ozone FS Namespace的并发控制
对于Ozone FS Namespace可能在实际的使用场景中会有超大规模的文件目录数的量级存储，那么这里面对于FS Namespace的并发控制就不能小视了。
社区目前的方案是在不考虑递归删除目录的操作情况，并发控制可以做到Directory目录级别。简单来说，我的所有操作控制在正在操作的Directory的目录级别，这基本属于最小锁粒度层面级别的。但是针对闭幕rename这种会存在跨目录间的操作，为了保证原子性，还需要引入一个全局锁的控制。总的来说，就是假设没有全局锁的控制时，就按照目录级别锁进行各自更新操作。
引用
[1]https://issues.apache.org/jira/browse/HDDS-2939 . Ozone FS namespace
