关注了就能看到更多这么棒的文章哦~
Jonathan Corbet
Gemini translation
原文链接:https://lwn.net/Articles/1055062/
文件系统似乎是那些问题已被充分理解、但总有人在努力寻求更好解决方案的许多领域之一。因此,即便经过了这么多年,Linux 内核中的文件系统开发依然保持着飞快节奏。在最近的消息中,EROFS 文件系统正朝着获得实用的页面缓存共享功能迈进,一个新的 NTFS 实现也即将问世,而 XFS 则可能很快就会获得一套自愈基础设施。
EROFS 页面缓存共享
正如其名称所示,增强只读文件系统(Enhanced Read-Only Filesystem,简称 EROFS)是一种用于只读数据的文件系统。EROFS 支持各种先进的文件系统特性,并提供高性能的数据压缩。它被应用于多种场景,其中最著名的或许是在 Android 设备上。EROFS 于 2019 年合并入 5.4 内核版本,自那以后一直在稳步发展。
EROFS 的一个常见用例是作为容器镜像的基础层。因此,在一个给定的机器上,一个 EROFS 文件系统通常会被挂载多次,并且可能存在同一个文件系统的多个细微差异的变体。例如,几个镜像可能包含不同的应用程序组合,但都拥有相同的 C 库。虽然 EROFS 在创建时会通过数据去重(deduplication)处理单个文件系统内的数据,但它无法对独立创建的文件系统执行此操作。文件在不同文件系统间的重复可能导致整个系统中出现多个打开的文件包含相同数据的情况,这些数据被放入页面缓存(page cache)时会浪费大量内存。如果能找到一种方法对这些页面缓存数据进行去重并消除内存浪费,那将是非常理想的。
2025 年初,Hongzhen Luo 发布了一个实现 EROFS 页面缓存共享的补丁系列。随后,Hongbo Li 接手并继续了这项工作;最新的发布版本是第 18 版。其工作原理是在创建时为文件系统内的每个文件分配一个指纹(fingerprint);该指纹随后用于检测包含相同数据的文件。
具体而言,EROFS 文件系统内的每个文件都会被赋予一个扩展属性;该属性的名称可以由创建者设置,但 trusted.erofs.fingerprint 似乎是标准用法。指纹的实际内容并未定义。一个逻辑上可行的方法是使用文件内容的加密哈希值,但正如 Gao Xiang 所说,它也可以只是由镜像创建者分配的一个整数值。当然,如果两个文件的内容不同,其指纹也应该不同。
如果文件系统是以 inode_share 选项挂载的,则会使用该指纹。另一个选项 domain_id 用于隔离用户;只有在同一个域 ID 下挂载的文件才会进行去重。如果没有这种限制,能够挂载 EROFS 文件系统的攻击者可能会给包含恶意内容的文件附加任意指纹,从而导致其他用户获取到这些恶意内容,而不是他们预期的文件。
当一个带有指纹的文件被打开时,EROFS 代码会创建一个内部索引节点(inode)来引用该文件中的数据。用户空间打开的文件会在内核中被重定向到那个去重 inode,该 inode 在内部与指纹相关联。随后打开具有相同指纹的文件将直接获取该去重 inode 的引用,读取操作也将被重定向到该 inode 的后端存储。结果是,所有这些文件将共享页面缓存中相同的 folio,从而消除了重复的内存占用。
在当前的实现中,使用指纹至少与直接 I/O(direct I/O)是不兼容的。
根据系统中运行的工作负载,页面缓存共享在最佳情况下可以将内存使用量减少近一半。因此,这个想法的吸引力并不令人意外。该补丁系列随着时间的推移发生了很大变化,许多评审意见也得到了解决,但仍有一些问题存在。例如,Christoph Hellwig 对该特性的安全性影响表示担忧,在支持该特性之前可能还需要进一步的说服。因此,虽然已经经历了 18 个版本的修订,但在该特性被合并之前,可能还会有更多的改动。
新的 NTFS
NTFS 是 Windows 的标准文件系统格式。人们通常认为,长期以来致力于与尽可能多的系统保持互操作性的 Linux 应该拥有一个良好的 NTFS 实现,但这一愿望从未真正实现。多年来,内核对 NTFS 的支持仅限于只读。想要完全访问 NTFS 文件系统的 Linux 用户只能使用在用户空间 FUSE 下运行的 ntfs-3g。
随着 2021 年 ntfs3 的到来,这种情况似乎发生了改变。这一实现提供了完整的 NTFS 访问权限,似乎正是社区一直在等待的,尽管当时有人担心该系统背后的支持程度可能不如预期。它在 5.15 版本中被合并,而原有的只读 NTFS 文件系统则在 2024 年的 6.9 版本中从内核中移除。
对 ntfs3 维护情况的担忧在某种程度上自其合并以来已成为现实。ntfs3 代码在 5.15 版本中刚合并时,通常预期在后续版本中会有相当频率的变更,以修复错误并添加更多特性。然而,在这种情况下,5.16 版本中恰好只有 4 个 ntfs3 补丁,5.17 中只有 1 个,5.18 中有 5 个,依此类推。节奏在 6.0 版本前后有所加快,但最近又有所下降。在过去的一年里,fs/ntfs3 共有 67 次提交。其中许多变更并非由其维护者(Konstantin Komarov)完成,而是由其他开发人员为了适配内核树中其他地方的变更而对 ntfs3 进行的修补。
2025 年 10 月,Namjae Jeon 提出了一个名为 ntfsplus 的替代 NTFS 实现;此后该文件系统更名为 ntfs,与旧的只读实现一致。Jeon 表示,这项工作的动力在于 ntfs3 仍然存在许多问题且维护不善;新的 ntfs 旨在成为一个维护更好、功能更全的 NTFS 实现。该补丁集的第五个修订版本已于 1 月 11 日发布。
该系列首先撤销了对只读 NTFS 文件系统的移除。Jeon 说,这段代码更加简洁,有详尽的注释,提供的可读性使得理解 NTFS 更加容易,因此比 ntfs3 代码库更适合作为持续开发的基础。随后,该系列添加了将该文件系统转变为真正的读写 NTFS 实现所需的代码。最后,该系列移除了 ntfs3 用来模拟旧只读实现的兼容性代码。
Jeon 表示,这个版本有很多优势。它使用 iomap 层(iomap layer)与内存管理和块子系统交互;相比之下,ntfs3 仍在使用较旧的缓冲头(buffer-head)接口。(应当指出,Komorov 有一个为 ntfs3 添加 iomap 支持的补丁目前正处于 linux-next 中)。此外还有一个配套项目在添加文件系统检查器。Jeon 声称,该文件系统通过的 fstests 测试比 ntfs3 多得多。一系列基准测试显示其性能优于 ntfs3,在某些工作负载下甚至高出 110%。
补丁集在邮件列表中出现后的短时间内演进迅速,许多评审意见已得到处理。新的文件系统似乎在功能上已经基本完备,但有一个显著的例外:它目前还不支持日志功能(journaling)。ntfs3 实现能够回放现有的日志(尽管 Jeon 表示该功能在我们的测试中未能正常工作)。根据封面信,下一步将是提供完整的日志支持。
内核社区通常对同一功能的多种实现不感兴趣,更希望看到渐进式的改进而非推倒重来;这在 Jeon 的道路上设置了巨大的障碍。即便如此,新代码似乎正在赢得文件系统开发者的支持;虽然仍有很多评审意见,但它们旨在改进代码而非质疑其存在的必要性。再次更换 NTFS 实现将是一个巨大的举措,但目前看来这并非不可想象。
XFS 自愈
XFS 文件系统往往与大型系统联系在一起;它旨在为拥有大量 CPU 的系统上的大规模文件提供扩展性。运行这类系统的组织通常也关注可靠性和数据完整性。近期在这些领域对 XFS 进行了大量工作;其中一部分就是来自 Darrick Wong 的 XFS 自主自愈基础设施(autonomous self-healing infrastructure)。
基于内核的基础设施本身并不会修复有问题的文件系统。它主要是一种报告机制,让用户空间守护进程能够了解问题;如何应对任何特定问题的决策可以在用户空间做出。该守护进程可能会通过杀死并重启容器、启动某种扫描(scrub)操作或尝试以其他方式纠正错误来进行响应。无论如何,这是一个涉及策略决策的复杂操作,最好在内核之外完成。
该系列添加了一个新的 ioctl 系统调用操作 XFS_IOC_HEALTH_MONITOR,它将向具有适当权限的进程返回一个文件描述符。每当发生值得关注的事件时,一个结构体就会被写入该文件描述符,供用户空间读取并做出反应。对于好奇的读者,这个补丁在开头解释了为什么决定将事件输出为二进制 C 结构体,而不是使用某种更高级的协议编码。
可以报告的事件多种多样,首先是 unmount 事件;它表示文件系统不再挂载,且不会再产生进一步的事件。还有一组用于报告元数据(metadata)损坏的事件,分为运行时发现损坏的病态(sick)元数据和由文件系统检查器检测到的损坏(corrupt)元数据。其他事件则报告介质和 I/O 错误。该系列还添加了一个 ioctl 系统调用操作,用于检查给定的文件描述符是否指向正在被监控的文件系统上的文件;这可以让用户空间守护进程确信其确实是在正确的文件系统上运行。
在用户空间方面,Wong 有一个代码库,其中包含一个旨在利用新接口的 xfs_healer 程序。对于感兴趣(且熟悉 troff 格式)的读者,有一个简短的帮助页面描述了这个工具;我们创建了该页面的渲染版本,有些人可能会觉得阅读起来更轻松一些。
内核补丁系列目前处于第六个修订版,且似乎趋于稳定。它可能会在不久的将来进入主线(mainline)。不过,将用户空间代码开发到让管理员信任其能在活跃的生产文件系统上运行的程度,可能还需要更长的时间。
LWN 评论概述:
读者们对这些文件系统的进展表达了不同的看法。针对新的 NTFS 实现,有用户质疑在安全意识日益增强的今天,是否有必要为了性能而放弃像 ntfs-3g 这样成熟的 FUSE 方案,转而使用可能增加攻击面的内核态驱动。对于 XFS 的自愈功能,有开发者详细介绍了 xfs_healer 守护进程的使用方法,包括如何开启反向映射和父指针等高级修复功能,并提醒该功能目前仍处于极具实验性的阶段。此外,还有讨论提到微软可能正在用 ReFS 逐渐取代 NTFS,以及关于 ZFS 和 Btrfs 等现代 COW(写时复制)文件系统当前状态和可靠性的疑问。
全文完LWN 文章遵循 CC BY-SA 4.0 许可协议。
欢迎分享、转载及基于现有协议再创作~
长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~


1万+

被折叠的 条评论
为什么被折叠?



