LWN：XFS在线检测和修复！

关注了就能看到更多这么棒的文章哦～

XFS online filesystem check and repair

By Jake Edge
June 15, 2023
LSFMM+BPF
DeepL assisted translation
https://lwn.net/Articles/934561/

Darrick Wong 多年来一直致力于 XFS online repair 工作，目前文件系统里内部的大部分工作已经完成并正在 review 中。剩下的主要是用户空间方面需要设置定期扫描和 repair 的间隔时间，因此他想在 2023 年 Linux 存储、文件系统、内存管理和 BPF 峰会上远程主持一个讨论。这次会议可能没有像他希望的那样进行，因为在这之前的会议中有关 unprevileged image mount 的讨论在一定程度上导致了偏离主题。

他当前的 XFS online repair 的 patch set “目前正在 Dave Chinner 的笔记本电脑上进行 review”，因此是时候开始讨论缺失的部分了。这意味着他将比平时更多地谈论用户空间的情况；目前有一个用户空间的控制程序来控制 online fsck 机制运行的频率。暂时还没有任何机制可以通知用户空间 online fsck 这一轮运行中发现的问题，也没有守护进程来监控这些通知从而进行任何动作，比如发起 repair 请求。他说内核中没有什么好的基础设施可以处理和调度这类工作。

[Darrick Wong]

他说，之前在 unprivileged-mounts 会议中关于使用 fsck 来确定镜像文件是否健全以及可以 mount 的讨论使他认为现在是讨论此类问题的好时机。

正如他指出的，已经有一个命令行程序 xfs_scrub ，它打开块设备和根目录，然后开始发布正确的 ioctl() 命令，但真正的使用场景并不应该是用这种方式来运行此工具。相反，它的想法是通过 systemd 服务来定期进行后台检查和 fix；他在设置这个环境上碰到点困难，但已经有一些东西可以正常工作起来了。然而，目前的做法根古老的定期 cron 工作没有太大区别，后者会将其结果报告到系统日志并希望管理员注意到。

他认为最好创建一个通知系统，允许系统动态地响应定期清理扫描所报告出来的事件。他还希望有一种方法可以让程序由各种原因来启动清理动作，例如 container manager 管理程序发现系统不太忙的时候就会在已 mount 的文件系统上启动清理。 Wong 说，也许这也可以以某种方式跟 unprivileged mount 机制结合起来。

因此，他想知道是否有任何用户空间开发人员对如何使用此功能有些想法。他可以“带着我的内核有色眼镜”继续开发，但他担心这可能不会给出最好的方案。有人试图唤回来 Lennart Poettering，因为他可能对此事有一些想法，但在茶歇后他还没有回到文件系统会议室。

Josef Bacik 表示，他通常依赖 Fedora 和其他发行版的人员来向他提供有关此类功能的反馈。发行版开发人员通常对如何使用这些东西有一些清晰的想法。因此，想要讨论可能适用于 online 清理程序的策略，那么他建议寻找来自 Linux 发行版的人员。

Ted Ts'o 重复了一些在这之前关于使用（offline） fsck 在 mount 镜像文件之前检查该文件的讨论。为了确保在完成 fsck 时映像文件不会被用户空间修改，Ts'o 表示需要事先将它们复制到用户空间无法访问的地方。与 XFS 计划添加的内核内 fsck 的一个区别可能是这里并不需要复制和快照步骤。他认为内核内的 fsck 可能没有这个要求，但这并不足以回答以这种方式使用 fsck 是否足够。

这时，Poettering 回来了，所以 Wong 重复了他之前说过的一些话。他说，online 清理器的工作最近变得更加紧迫，因为“我原本以为没有发行版允许用户在没有特权的情况下挂载 XFS 文件系统，但是看起来这种情况比我想象得要多”。 XFS 最近也做出了一些努力来标记它所看到的奇怪问题（“很奇怪的或者是完全错误的 metadata”），但这并没有根 fsnotify 事件（如 ext4 一样）用来通知用户空间此类损坏。 XFS 通常确切地知道问题是什么，可以以某种方式将其写在通知里面，希望有人正在监听并采取适当的措施。对于某些文件系统来说，可能需要 umount 然后对文件系统进行 fsck，而 XFS 可以使用 online repair 机制。

Poettering 表示，目前让台式机自动 mount 那些可插拔的存储设备的做法是“愚蠢的”。 Chrome OS 所采用的仅通过用户空间驱动程序来 mount 某些特定文件系统类型（例如 VFAT）的方法要好得多，其他桌面也应该采用这种方法。他说，桌面使用场景通常用于 U 盘，人们通常不会在此类介质上使用 XFS，因此根本不应该自动 mount 这类磁盘。

不过，对于在 container 中挂载文件系统映像，他认为是否要信任应该由 dm-verity 来确保，如他之前的演讲中所述。 Ts'o 曾说过， fsck 可能足以证明 ext4 映像不会损害内核，因此 Poettering 想知道 Wong 是否会对 XFS 有同样的保证。Wong 认为这个问题很难说。 “一旦我说‘是’，世界上的每个人都会盯着他们的 fuzzer 测试工具来尝试找到 fsck 无法捕捉到的那些东西”。也就是说，他总体上同意 Ts'o 的观点， fsck ，无论是 online 还是 offline 的，都应该足够强大，要能捕获到任何不良文件系统，但这并不能绝对保证，因为总是会有 bug 的。

Poettering 指出，XFS 的 online 检查不能用于确保可信，因为需要首先 mount 文件系统。Wong 同意这个说法，但发行版提供商签名的映像文件情况如何呢？。 Poettering 和 Christian Brauner 表示，签名过的映像文件是完全可信的，或者至少如果它们不可信的话那也是用户空间的责任。 Kent Overstreet 表示， fsck 在任何情况下都不能用于确保信任，因为恶意设备可能会更改检查之中获得的数据。 Ts'o 说，虽然对于 USB 设备来说确实如此，但安装在 container 中的本地映像文件的快照/复制要求就消除了这种可能。

Overstreet 认为，要求提供进行复制，对于用户来说是过于繁重，很难落实的。相反，他认为“作为文件系统实现者，我们应该做的负责任的事情是开始更加认真地在运行时强化我们的代码”。他说，XFS 对 metadata 进行了大量的读写时验证以及模糊测试，就像 Overstreet 的 bcachefs 一样，因此“我们的情况可能不会像我们想象的那么糟糕”。

Brauner 想要澄清一点，正在讨论的复制以及和 fsck 不是用户控制的东西，而是由 mount daemon 守护进程处理。Overstreet 坚称，进行复制仍然是不可接受的做法，并且“人们希望很快就会希望能够在不受信任的云环境中安装映像文件”。

Bacik 表示，会议当时正在“偏离话题”。他说，Wong 感兴趣的是用户空间会对哪些类型的通知感兴趣，以及如何围绕这些通知来设计处理策略的问题；Wong 对此表示同意。 Poettering 表示，他“不是存储专家”，因此他不知道他们可能需要什么样的策略，但他认为，当受影响的服务所依赖的文件系统出现错误时，直接把受影响的服务关闭掉就是最安全的做法。如果 systemd 收到此类通知，则可以直接设置成把受影响的服务关闭掉就行。

Ts'o 表示，应该咨询那些运行此类服务的人，了解如何处理这些事件。例如：Kubernetes 使用者们真正想要什么？他们可能想要关闭受影响的服务，但给这些服务一个短暂的时间来发送“再见吧，残酷的世界”之类的消息。 Wong 提到的 ext4 通知是专门为实现很类似 Google Kubernetes 的容器管理器 Borg 添加的；维护这些系统的人员希望能够在文件系统损坏时关闭服务。

Wong 表示，在为大型数据库供应商（Oracle）工作时情况有些不同。除了根文件系统之外，XFS 的大部分用途是用于“非常大的数据分区，我们希望能够在 100TB 数据分区上至少进行简单的修复的同时能尝试保持 VM 运行”。在任何一个时刻，虚拟机或容器中运行的工作负载可能不会访问整个 100TB 内容，因此有机会在应用程序注意到之前就把问题修复好了。 “我们至少想尝试在飞机飞行时安装新的发动机，从而避免紧急着陆。”恢复 100TB（甚至更多）的话可能需要很长时间，最好避免这种情况。

Poettering 想知道，增加一个 mount 选项让 XFS 检测到异常就简单地要求 XFS 运行其 online 清理器，会不会是一种合理的方法。 “为什么要让用户空间牵涉进来发起 online 文件系统检查？”用户空间更适合对系统的其他部分执行操作，例如关闭相关服务，因此 XFS 把问题报告给用户空间并等它说一句“你自己修复吧”的做法并没有什么好处。 Wong 表示，他本来计划是写一个 XFS 守护进程，用来在需要时接收通知并安排清理工作。

最后，他描述了为 XFS 进行的一些模糊测试，XFS 使用 XFS debugger 来“遍历整个文件系统中每个 metadata 对象的每个字段并对它们进行模糊测试”。这就是为什么 XFS QA 测试套件需要近一周才能运行完成；它花费了大量时间进行模糊测试和检查，以确保修复工具可以注意到问题并可以用 online 和 offline 的方式来修复。他也同时向 fstests 添加了一些 ext4 metadata block 的模糊测试，但没有达到与 XFS 模糊测试相同的细致程度。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～