2 个不稳定版本
使用旧的 Rust 2015
0.2.0 | 2017 年 2 月 5 日 |
---|---|
0.1.0 | 2017 年 2 月 4 日 |
370 在 并发 中
7KB
124 行
TFS 已被 RedoxFS 取代,并且不再维护,TFS 的多数功能已被集成到 RedoxFS 中
TFS:下一代文件系统
TFS 是一个模块化、快速且功能丰富的下一代文件系统,采用现代技术以实现高性能、高空间效率和高度可扩展性。
TFS 是由于 Redox OS 对现代文件系统的需求而创建的,作为对 ZFS 的替代品,由于它的单体设计,ZFS 的实现速度较慢。
TFS 受 ZFS 的启发,同时它旨在模块化且易于实现。
TFS 与 terminalcloud 的同名文件系统无关。
尽管许多组件已完成,但 TFS 本身尚未准备好使用。
设计目标
TFS 是以下目标的产物:
- 并发
TFS 包含非常少的锁,并旨在尽可能适合多线程系统。它使用多个真正并发的结构来管理数据,并且通过核心数量进行线性扩展。 这是 TFS 最重要的特性。
- 异步
TFS 是异步的:操作可以独立发生;磁盘的读写操作不需要阻塞。
- 全盘压缩
TFS 是第一个通过我们称为 RACC(随机访问簇压缩)的方案实现完整全盘压缩的文件系统。这意味着每个簇都只进行压缩,对性能的影响微乎其微。据估计,您将获得 60-120% 的更多可用空间。
- 修订历史
TFS 存储每个文件的修订历史记录,而不增加额外的开销。这意味着您可以恢复任何文件的早期版本,自动备份系统,且不会因为复制而产生额外的开销。
- 数据完整性
与 ZFS 类似,TFS 存储文件的完整校验和(不仅仅是元数据),并且在此基础上,它是在父块中完成的。这意味着几乎所有的数据损坏都会在读取时被发现。
- 写时复制语义
类似于 Btrfs 和 ZFS,TFS 使用写时复制语义,这意味着永远不会直接覆盖簇,而是复制并写入新的簇。
- O(1) 递归复制
像一些其他文件系统一样,TFS 可以在常数时间内进行递归复制,但有一个独特的附加功能:即使经过变异,TFS 也不会进行复制。如何实现?它将文件的各个部分分别维护,这样只需要复制已更新的部分。
- 保证原子性
系统永远不会进入不一致的状态(除非有硬件故障),这意味着意外断电永远不会损坏系统。
- 改进的缓存
TFS 在缓存磁盘以加速磁盘访问方面投入了大量精力。它使用机器学习来学习模式并预测未来的使用,以减少缓存未命中次数。TFS 还压缩内存缓存,减少了所需的内存量。
- 更好的文件监控
CoW非常适合高性能、可扩展的文件监控,但不幸的是,只有少数文件系统采用了这种功能。TFS 就是其中之一。
- 所有内存安全
TFS 只使用用 Rust 编写的组件。因此,只有在标记为 unsafe 的代码中才可能出现内存不安全,而这会得到额外的仔细检查。
- 全面测试
TFS 致力于全面测试。这通过立即揭示大量错误,提供了相对较强的正确性保证。
- SSD 友好
TFS 通过重新定位已死亡的扇区来避免 SSD 中的写入限制。
- 改进的垃圾收集
TFS 使用 Bloom 过滤器进行空间高效且快速的垃圾收集。TFS 允许文件系统垃圾收集器在后台运行,而不会阻塞文件系统的其余部分。
常见问题解答
为什么您将 SPECK 作为默认加密算法?
- SPECK 是一种相对较新的加密算法,但已经经历了许多(无效的)密码分析,因此相对安全。它具有非常好的性能和简单的实现。可移植性是 TFS 设计的重要组成部分,真正没有侧信道攻击的可移植 AES 实现比许多人想象的要困难(尤其是,大多数可移植实现中的 SubBytes 都存在问题)。SPECK 没有这个问题,因此可以以最小的努力安全地可移植实现。
TFS 和 ZFS 有多相似?
- 实际上并不相似。它们共享许多基本思想,但除此之外,它们基本上没有关联。但 ZFS 的设计在很大程度上影响了 TFS。
TFS 仅限于 Redox 吗?
- 不是,也从未计划仅限于 Redox。
全盘压缩是如何工作的?
- 据我所知,全盘压缩是 TFS 独有的。它通过将尽可能多的“页面”(虚拟数据块)收集到一个“簇”(分配单元)中来实现。通过这样做,可以通过简单地解压缩相应的簇来读取页面。
为什么 ZMicro 那么慢?它会影响 TFS 的性能吗?
- ZMicro 那么慢的原因是因为它在位级别上工作,以性能为代价提供了出色的压缩率。这种可怕的低性能通过减少写入次数得到了补偿。实际上,超过 50% 的使用 ZMicro 的分配将只写入一个扇区,而不是 3 个。其次,无论您的磁盘有多快,它都不会接近 ZMicro 的性能,因为磁盘操作本身就很慢,从长远来看,压缩的性能实际上并不重要。
可扩展哈希或 B+ 树?
- 都不是。TFS 使用树和哈希表的组合:嵌套哈希表,这是一种哈希树的形式。其理念是在桶中创建一个新的子表,而不是重新分配。
关于设计的资源
我写过关于 TFS 设计的一些文章。
- SeaHash:解释 - 这描述了为 TFS 设计的默认校验和算法。
- 关于随机访问压缩 - 这篇文章描述了用于随机访问压缩的算法。
- 三进制作为预测残差码 - 这种使用的相关性与创建一个好的自适应(无头)熵压缩器有关。
- LZ4是如何工作的 - 这描述了LZ4压缩算法的工作原理。
- 嵌套哈希表中的冲突解决 - 这描述了我们用于目录结构的嵌套哈希表方法。
- 原子哈希表 - 这描述了并发、内存中的哈希表/键值存储。
规范
完整的规范可以在 specification.tex
中找到,要渲染它请安装 texlive
或其他带有XeTeX的发行版,并运行
xelatex --shell-escape specification.tex
然后打开名为 specification.pdf
的文件
lib.rs
:
线程特定对象。
这是一个在通常的线程本地存储之上的抽象,增加了一种对于每个线程都有值的特殊类型。
这意味着您可以动态创建TLS变量,而不是像经典的那样固定静态变量。这意味着您可以将对象引用存储在结构体中,并在同一线程中有多个。
它通过持有包含唯一对象ID与对象指针关联的二叉树映射的TLS变量来实现。
性能方面,这并不是最优的,但与其他大多数方法相比,它是可移植的。