1 个不稳定版本
使用旧的 Rust 2015
0.1.0 | 2017年2月19日 |
---|
#924 in 文件系统
95 每月下载量
在 8 个 Crates 中使用(7 个直接使用)8 crates (7 directly)
1KB
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 存储每个文件的修订历史,而不增加额外的开销。这意味着您可以将任何文件回滚到早期版本,自动备份系统,而不需要从复制中产生额外开销。
- 数据完整性
TFS,类似于 ZFS,存储文件的完整校验和(不仅仅是元数据),并且在父块上完成。这意味着在读取时几乎可以检测到所有数据损坏。
- 写时复制语义
类似于 Btrfs 和 ZFS,TFS 使用 CoW 语义,这意味着永远不会直接覆盖任何集群,而是复制到新集群并写入。
- O(1) 递归复制
像其他一些文件系统一样,TFS 可以以常数时间进行递归复制,但有一个独特的补充:TFS 即使在修改后也不会复制。如何?它独立维护文件的各个部分,这样只需复制已更新的部分。
- 保证原子性
系统永远不会进入不一致的状态(除非硬件故障),这意味着意外断电永远不会损坏系统。
- 改进的缓存
TFS在缓存磁盘以加快磁盘访问速度方面投入了大量努力。它使用机器学习来学习模式并预测未来的使用情况,以减少缓存未命中次数。TFS还压缩内存缓存,减少了所需的内存量。
- 更好的文件监控
CoW非常适合高性能、可扩展的文件监控,但遗憾的是,只有少数文件系统采用了这种技术。TFS就是其中之一。
- 所有内存安全
TFS仅使用用Rust编写的组件。因此,只有在标记为unsafe的代码中才可能出现内存不安全,这些代码会被额外仔细检查。
- 全面覆盖测试
TFS旨在在测试方面实现全面覆盖。这通过立即揭示大量错误类别,为正确性提供了相对强大的保证。
- SSD友好
TFS试图通过重新定位已死扇区来避免SSD的写限制。
- 改进的垃圾回收
TFS使用Bloom过滤器进行高效且快速的垃圾回收。TFS允许文件系统垃圾回收器在后台运行,而不会阻塞文件系统的其余部分。
常见问题解答(FAQ)
为什么您使用SPECK作为默认加密算法?
- SPECK是一种相对较新的加密算法,尽管它已经经历了大量的(无效的)密码分析,但相对较为安全。它具有非常好的性能和简单的实现。可移植性是TFS设计的重要部分,而真正可移植的AES实现(没有副作用通道攻击)比许多人想象的要困难得多(特别是,大多数可移植实现中存在SubBytes的问题)。SPECK没有这个问题,因此可以以最小的努力安全地实现可移植性。
TFS和ZFS有多相似?
- 实际上并不相似。它们共享许多基本思想,但除此之外,它们基本上是无关的。但ZFS的设计对TFS的设计产生了很大影响。
TFS仅限于Redox系统吗?
- 不,它从未计划仅限于Redox系统。
整盘压缩是如何工作的?
- 据我所知,整盘压缩是TFS独有的。它通过将尽可能多的“页面”(虚拟数据块)收集到一个“簇”(分配单元)中来实现。通过这种方式,可以通过简单地解压缩相应的簇来读取页面。
为什么ZMicro如此慢?它会影响TFS的性能吗?
- ZMicro之所以如此慢,是因为它在位级别上工作,以牺牲性能为代价提供了出色的压缩比。这种可怕的性能是通过减少写入次数来弥补的。实际上,使用ZMicro的分配中有超过50%只会写入一个扇区,而相比之下,3个扇区。其次,无论你的磁盘有多快,它都无法接近ZMicro的性能,因为磁盘操作本质上是缓慢的,从整体角度来看,压缩性能实际上并不重要。
可扩展哈希或B+树?
- 都不是。TFS使用树和哈希表的组合:嵌套哈希表,一种哈希树的形式。其想法是在桶中创建一个新的子表,而不是重新分配。
设计资源
我写了一些关于TFS设计的文章。
- SeaHash: 解释 - 这篇博客解释了为TFS设计的默认校验和算法。
- 关于随机访问压缩 - 这篇博客描述了用于随机访问压缩的算法。
- LZ4工作原理 - 这篇博客描述了LZ4压缩算法的工作原理。
- How LZ4 works - 这篇博客描述了LZ4压缩算法的工作原理。
- 嵌套哈希表中的冲突解决 - 这描述了我们在目录结构中使用的嵌套哈希表方法。
- 原子哈希表 - 这描述了并发、内存中的哈希表/键值存储。
规范
完整规范可以在 specification.tex
中找到,要渲染它请安装 texlive
或其他带有 XeTeX 的发行版,并运行
xelatex --shell-escape specification.tex
然后打开名为 specification.pdf
的文件
lib.rs
:
对 type_name
API 的安全包装。