项目介绍 - Hexilee/tifs GitHub Wiki
一次给朋友安利 TiDB 时，得知他只有一台机器，那跑 TiDB 集群有什么优势呢？我告诉他可以每块盘跑一个 TiKV 实例，这样实现了多磁盘容灾，就不需要组 RAID 了。
当然最后一句只是玩笑话，毕竟 TiDB 是个数据库，只能做到数据容灾。但转念一想，如果把文件系统的数据也存进 TiKV，不就能做到文件系统容灾了吗？ 于是我们花了几天写出了 TiFS 的雏形 ——— 一个充满 bug 经常死锁的 POSIX 文件系统，但令人兴奋的是这个想法确实可行。
雏形出来后，我们需要考虑更多的问题。比如文件系统基于 TiKV 的优势是什么？又比如 CAP 应该如何取舍？相比于常见的分布式文件系统存储后端，我认为 TiKV 最大的优势是天然支持分布式事务，基于此我们可以保证文件系统的严格一致性。如果我们要保证严格一致性，即我们要构建一个 CP 系统，那适用场景应当是通用 POSIX 文件系统，完全覆盖本地文件系统的需求，另外还能实现跨机器的文件协作或满足其它分布式应用的文件存储需求。
更酷的是，依赖文件系统的单机应用运行在 TiFS 上就变成了一个分布式应用，比如 sqlite on TiFS 就是另一个分布式关系型数据库！
TiFS 一共需要在 TiKV 中存储系统元数据（Meta）、文件元数据（Inode）、文件块（Block）、文件句柄（FileHandler）、符号链接（SymbolicLink）、目录（Directory）和文件索引（FileIndex）共七种值。其中文件块是用户写入的透明数据，符号链接只存储目标路径，而另外五种都是序列化的结构数据。
系统元数据仅有一个用来生成文件序列号（inode number）的整数，其结构如下：
struct Meta {
inode_next: u64,
}整个文件系统只有一份系统元数据，且仅在 mknod 和 mkdir 的过程中被更新。
每个文件都有一份对应的文件元数据，其结构如下：
struct Inode {
file_attr: FileAttr,
lock_state: LockState,
inline_data: Option<Vec<u8>>,
next_fh: u64,
opened_fh: u64,
}其中 file_attr 字段中存储了 POSIX 文件系统所必要的元数据，比如文件序列号、文件大小、块数量等，详细结构可参考文档；lock_state 字段存储了当前的上锁状态和持锁人，用于实现 flock；inline_data 字段可能会存储少量文件内容，用于提升小文件的读写性能；next_fn 字段是一个自增整数，用于生成文件句柄；opened_fn 字段用于记录打开状态的文件句柄数量。
文件系统对用户的每次 open 调用生成一个文件句柄，其结构如下：
struct FileHandler {
cursor: u64,
flags: i32,
}其中 cursor 字段存储了此句柄的文件光标位置；flags 字段存储了句柄的读写限制。
每个目录都需要存储一份子文件列表以实现 readdir，列表中的每一项都存储了一个子文件的文件序列号、文件名和文件类型，其结构如下：
type Directory = Vec<DirItem>;
struct DirItem {
ino: u64,
name: String,
typ: FileType,
}我们可以直接遍历目录来实现文件查找，但为每个文件链接创建文件索引显然是更高效的解决方案。每个文件索引仅含有目标文件的序列号，其结构如下：
struct Index {
ino: u64,
}TiKV 本身只提供简单的键值对存储，键和值都是不定长的字节数组，所以设计系统之前需要给键分逻辑区域。TiFS 一共有系统元数据、文件元数据、文件块、文件句柄和文件索引五种键，其中文件块类的键可以用来存储文件块数据、符号链接和目录，另外四种键都只用于存储前文提到的同名值。
我们根据第一个字节区分不同类的键，这个字节可称为键的域（scope）。键的字节数组通用布局如下：
+ 1byte +<--------------------------------+ dynamic size +---------------------------------------->+
| | |
| | |
| | |
| | |
| | |
| | |
| v v
+--------------------------------------------------------------------------------------------------+
| | |
| scope | key |
| | |
+-------+------------------------------------------------------------------------------------------+
系统元数据域只有唯一键值对，其键的字节数组布局如下：
+ 1byte +
| |
| |
| |
| |
| |
| |
| v
+-------+
| |
| 0 |
| |
+-------+
文件元数据域的键仅含有大端序编码的文件序列号，这样所有的文件元数据都顺序地存储在 TiKV 上，可以在 statfs 操作时直接用 TiKV 的 scan 接口扫描出所有文件的元数据。
文件元数据键的字节数组布局如下：
+ 1byte +<-----------------------------------+ 8bytes +------------------------------------------->+
| | |
| | |
| | |
| | |
| | |
| | |
| v v
+--------------------------------------------------------------------------------------------------+
| | |
| 1 | inode number |
| | |
+-------+------------------------------------------------------------------------------------------+
文件块域的键由文件序列号和块序列号的大端序编码构成，这样同一文件的所有的文件块都顺序地存储在 TiKV 上，可以在读取大段数据时直接使用 TiKV 的 scan 接口一次扫描出所需的文件块。
文件块键的字节数组布局如下：
+ 1byte +<----------------- 8bytes ---------------->+<------------------- 8bytes ----------------->+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| v v v
+--------------------------------------------------------------------------------------------------+
| | | |
| 2 | inode number | block index |
| | | |
+-------+-------------------------------------------+----------------------------------------------+
文件句柄域的键由文件序列号和句柄号的大端序编码构成，其字节数组布局如下：
+ 1byte +<----------------- 8bytes ---------------->+<------------------- 8bytes ----------------->+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| v v v
+--------------------------------------------------------------------------------------------------+
| | | |
| 3 | inode number | file handler |
| | | |
+-------+-------------------------------------------+----------------------------------------------+
文件索引的键由大端序编码的目录文件序列号和 utf-8 编码的文件名构成，其字节数组布局如下：
+ 1byte +<----------------- 8bytes ---------------->+<-------------- dynamic size ---------------->+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| v v v
+--------------------------------------------------------------------------------------------------+
| | | |
| 4 | inode number of parent directory | file name in utf-8 encoding |
| | | |
+-------+-------------------------------------------+----------------------------------------------+
TiKV 同时支持乐观事务和悲观事务，但由于 Rust 版客户端只提供了实验性的悲观事务支持，以及无冲突情况下悲观事务性能较差，TiFS 只使用了乐观事务。
目前我们还没有给 TiFS 写测试，开发过程中我们一直以 pjdfstest 为正确性基准，但它并不能覆盖读写正确性和并发正确性，后面需要再跟进其它的测试。从理论上来说 TiFS 的读写性能的影响因样里素主要有三个：文件系统块大小、网络带宽延迟和负载块大小。下面我们给出了一份 benchmark 的结果，并针对读写 IOPS 和读写速度作出了四张图表。
另外，过大的文件块可能会导致 RocksDB 性能不佳，我们尝试开启 Titan 以避免不必要的值拷贝。
我们首先来讨论 IOPS 的变化规律，如下两张图分别是顺序写 IOPS 和顺序读 IOPS 随负载块大小的变化，四条折线代表不同的文件系统块大小和数据副本数（TiKV 实例数）。
由于顺序读写的 IO 操作是线性的，每次 IO 操作都是一次 TiKV 事务。如果我们忽略每次 IO 操作之间的细微区别，那一次 IO 操作的耗时
只考虑读的情况，$T_f$ 与负载块大小正相关；
TiKV 是个非常复杂的系统，其内部也可分为逻辑耗时、磁盘 IO 耗时和网络耗时。本文在性能分析时暂且将 TiKV 简化，只考虑单副本的情况。
图读 IOPS 随负载大小变化 中，文件块和负载块均为 4K 时，随着负载的增大
图中横坐标为对数距离，且取样点过少，斜率仅供参考。
顺序写数据时，如果负载块小于文件块，则 TiFS 需要先读一个脏文件块，会造成额外的
另外我们可以发现，负载块和文件块为 4K 或 64K 时的 IOPS 的几乎相等的。此时每秒最小流量
读写速度等于 IOPS 与负载块的乘积，而 IOPS 在负载块 4K 到 1M 之间没有剧烈变化，我们很容易就能看出负载块 1M 时读写速度达到最大值。下面两张是负载块 1M 时不同集群配置下的读写速度对比图。
文件块 64K 下未开启 Titan 的对比图已有单副本数据，三副本数据仅供参考，未进行重复对比。
我们可以看到写速度受文件块大小和 Titan 的影响比较大，读速度则几乎不受影响。文件块越小，TiKV 需要写入的键值对越多，导致了额外耗时；但文件块过大会导致 RocksDB 性能不佳，开启 Titan 可以得到明显的性能提升。
TiFS 后面的主要工作集中在正确性验证和性能调优。正确性验证部分包括找其它的开源文件系统测试套件和自建测试。性能调优部分包括 TiFS 的本身的调优工作和 TiKV 的高性能使用，以降低固有延迟。如果你对这个项目感兴趣，欢迎来试用或讨论 https://github.com/Hexilee/tifs。