文件系统通用性
本方向将研究 ZenFS 以及其他通用的文件系统 在 ZNS 上的应用。
让 ZenFS 更加通用
减少对 RocksDB 的依赖
当前 ZenFS 对 RocksDB 有许多依赖，这与 ZenFS 设计时的目的有关。ZenFS 被设计为 RocksDB 的对 Zoned Block Device 上的文件管理系统，数据读写完全由 RocksDB 管理，数据结构、程序日志、文件系统接口、测试方法等都在 RocksDB 代码当中，并不是 ZenFS 的逻辑。ZenFS 完全作为 RocksDB 的一个插件存在，无法独立编译也无法直接运用在其他程序中，既不方便开发也不方便使用。
当前，为了减少对 RocksDB 的依赖，我们的解决方案是将 RocksDB 首先编译为静态代码库 librocksdb.a，然后将这个静态库和所有的头文件安装到系统的搜索路径中，从而让一个独立的 ZenFS 能够使用其中的头文件定义和静态代码。
这其中是有许多问题的，例如 RocksDB 利用 Configurable 的基类完成了基于字符串到对象的对象工厂，但是如果将其编译为 librocksdb.a，就无法对其他使用到这个 .a 文件的程序完成这个工厂的查找过程。
TODO: 解决方案。
文件通用性
当前 ZenFS 的文件存储逻辑为..... TODO
Record 在磁盘上的结构可以总结如下：
| 种类 | 长度 | 可能的作用 |
|---|---|---|
| header | zMetaHeaderSize==(sizeof(uint32_t) * 2) | 记录数据块大小和校验和的信息 |
| data | record_sz | 存储实际的记录数据 |
| 校验和 | sizeof(uint32_t) | 用于校验数据完整性的校验和 |
以下是 header 的结构总结：
| 字段名称 | 字段类型 | 描述 |
|---|---|---|
| record_crc | uint32_t | 记录的 CRC 校验和 |
| record_sz | uint32_t | 记录的大小（字节数） |
其中，header 保存了 record_sz 和 record_crc，record_sz 是 data 的长度，record_crc 是 data 的校验和。data 中存储了实际的记录数据。actual_crc 是根据 data 和 record_sz 计算出的校验和，与 record_crc 进行比较以确认数据完整性。
一个 ZoneFile 在存储介质上的结构：
| 种类 | 长度 | 作用 |
|---|---|---|
| 文件 ID (File ID) | 4 字节 | 用于唯一标识文件 |
| 文件大小 (File Size) | 8 字节 | 记录文件大小 |
| 寿命提示 (Write Lifetime Hint) | 4 字节 | 用于提示写入寿命 |
| 区间 (Extent) | 可变长度 | 记录文件的一个区间 |
| 修改时间 (Modification Time) | 8 字节 | 记录文件最近一次修改的时间戳 |
| 活动区间的开始 (Active Extent Start) | 8 字节 | 记录当前活动区间的开始位置 |
| 是否稀疏 (Is Sparse) | 1 字节 | 标记文件是否为稀疏文件 |
| 关联文件名 (Linked Filename) | 可变长度 | 记录与该文件有关联的其他文件名 |