| title | author | date | summary | tags | katex | ||
|---|---|---|---|---|---|---|---|
TiFS 能存数据，为什么不能存文件？ |
|
2021-04-01 |
本篇文章的作者为龙姐姐说的都队的李晨曦，他们团队在本次Hackathon 比赛中构建了一个基于 TiKV 的分布式 POSIX 文件系统 TiFS，继承了 TiKV 强大的分区容错和严格一致性特性，为 TiKV 生态开辟了一个新的领域。 |
|
true |
本篇文章的作者为龙姐姐说的都队的李晨曦，他们团队在本次 Hackathon 比赛中构建了一个基于 TiKV 的分布式 POSIX 文件系统 TiFS，继承了 TiKV 强大的分区容错和严格一致性特性，为 TiKV 生态开辟了一个新的领域。
一次给朋友安利 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 {
flags: i32,
}每个目录都需要存储一份子文件列表以实现 readdir，列表中的每一项都存储了一个子文件的文件序列号、文件名和文件类型，其结构如下：
type Directory = Vec<DirItem>;
struct DirItem {
ino: u64,
name: String,
typ: FileType,
}我们可以直接遍历目录来实现文件查找，但为每个文件链接创建索引显然是更高效的解决方案。每个文件索引仅含有目标文件的序列号，其结构如下：
struct Index {
ino: u64,
}TiKV 本身只提供简单的键值对存储，键和值都是不定长的字节数组，所以设计系统之前需要给键分逻辑区域。TiFS 一共有系统元数据、文件元数据、文件块、文件句柄和文件索引五种键，其中文件块类的键可以用来存储文件块数据、符号链接和目录，另外四种键都只用于存储前文提到的同名值。
我们根据第一个字节区分不同类的键，这个字节可称为键的域（scope）。键的字节数组通用布局如下：
系统元数据域只有唯一键值对，其键的字节数组布局如下：
文件元数据域的键仅含有大端序编码的文件序列号，这样所有的文件元数据都顺序地存储在 TiKV 上，可以在 statfs 操作时直接用 TiKV 的 scan 接口扫描出所有文件的元数据。
文件元数据键的字节数组布局如下：
文件块域的键由文件序列号和块序列号的大端序编码构成，这样同一文件的所有的文件块都顺序地存储在 TiKV 上，可以在读取大段数据时直接使用 TiKV 的 scan 接口一次扫描出所需的文件块。
文件块键的字节数组布局如下：
文件句柄域的键由文件序列号和句柄号的大端序编码构成，其字节数组布局如下：
文件索引的键由大端序编码的目录文件序列号和 utf-8 编码的文件名构成，其字节数组布局如下：
TiKV 同时支持乐观事务和悲观事务，但由于 Rust 版客户端只提供了实验性的悲观事务支持，以及无冲突情况下悲观事务性能较差，目前TiFS 只使用了乐观事务。
TiFS 可以用于大文件存储，但它相比于现有的大文件存储方案没有特别的性能或存储效率上的优势，它的主要使用场景是小文件读写和复杂的文件系统操作。git 远程仓库可以直接使用 TiFS 存储项目并运行 git 任务，比如 rebase 或 cherry-pick，而无需先转存到本地文件系统；多节点应用读写同一文件时可以直接使用 flock 来解决冲突。它的空间管理无需复杂的 SDK 或 API 接入，只需要调用简单的文件系统 API 或 shell 脚本。
另外，像文章开头所说的，支持多实例协作的单机应用运行在 TiFS 上就可能变成分布式应用，如运行在 TiFS 上的 SQLite 就成了分布式关系型数据库。当然这种场景对单机应用本身的要求比较严苛，首先应用本身得支持单机多实例，另外尽量不依赖 page cache 或其它缓存以避免写入不可见。
目前我们还没有给 TiFS 写测试，开发过程中我们一直以 pjdfstest 为正确性基准并最终通过了它。但 pjdfstest 并不能覆盖读写正确性和并发下正确性，后面需要再跟进其它的测试。
从理论上来说 TiFS 的读写性能的影响因素主要有三个：文件系统块大小、网络带宽延迟和负载块大小。下面我们给出了一份 benchmark 的结果，并针对读写
我们首先来讨论
由于顺序读写的 IO 操作是线性的，每次 IO 操作都是一次 TiKV 事务。如果我们忽略每次 IO 操作之间的细微区别，那一次 IO 操作的耗时
只考虑读的情况，$T_f$ 与负载块大小正相关；
TiKV 是个非常复杂的系统，其内部也可分为逻辑耗时、磁盘 IO 耗时和网络耗时。本文在性能分析时暂且将 TiKV 简化，只考虑单副本的情况。
图读
图中横坐标为对数距离，且取样点过少，斜率仅供参考。
顺序写数据时，如果负载块小于文件块，则 TiFS 需要先读一个脏文件块，会造成额外的
另外我们可以发现，负载块和文件块为
读写速度等于
文件块
$64K$ 下未开启 Titan 的对比图已有单副本数据，三副本数据仅供参考，未进行重复对比。
我们可以看到写速度受文件块大小和 Titan 的影响比较大，读速度则几乎不受影响。文件块越小，TiKV 需要写入的键值对越多，导致了额外耗时；但文件块过大会导致 RocksDB 写入性能不佳，开启 Titan 可以减少不必要的值拷贝，明显提升性能。
TiFS 在架构上存在的一个问题是文件块存储成本比较高。TiKV 采用多副本冗余，空间冗余率（实际占用空间/写入数据量）一般 3 起步；而像 HDFS 或 CephFS，JuiceFS 等支持 EC 冗余模式的分布式文件系统冗余率可降到 1.2 到 1.5 之间。EC 冗余在写入和重建数据时需要编解码，均需要额外的计算资源。其在写入时可以降低网络开销和存储成本，但重建时一次需要读取多个数据块，有额外的网络开销，是一种牺牲部分读性能以降低写入时网络开销及存储成本的冗余策略。
目前 TiKV 要支持 EC 冗余还比较困难，后面 TiFS 会尝试支持 EC 冗余的对象存储来存文件块以降低存储成本，但近期的工作还是集中在正确性验证和性能调优。正确性验证部分包括找其它的开源文件系统测试和自建测试。性能调优部分包括 TiFS 的本身的调优工作和 TiKV 的高性能使用，以降低固有延迟。如果你对这个项目感兴趣，欢迎来试用或讨论。