LWN：suspend 时冻结文件系统！

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

Freezing filesystems for suspend

By Jake Edge
April 24, 2025
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/1018341/

有时麻烦就像开了的罐头里的蠕虫一样会不断增加。James Bottomley 最近就遇到了这种情况；他在 2025 年 Linux 存储、文件系统、内存管理和 BPF 大会 (LSFMM+BPF) 的文件系统（filesystem）讨论环节中主持了一场会话，讨论了系统挂起（suspend）和恢复（resume）时文件系统的行为。正如他在议题提案中所述，他遇到这个问题是因为他需要一种方法来在系统恢复后重新同步（resynchronize）efivarfs 的内容，并认为应该有相应的应用程序接口（API）可用。但是，正如后续讨论线程所示，文件系统冻结（filesystem freeze）和解冻（thaw）的代码从未被系统范围挂起（system-wide suspend）和恢复（system-wide resume）的代码使用过。然而，由于日程安排上的失误，我们中有几个人错过了 Bottomley 的会话，包括一直在努力将这两部分功能连接起来的 Luis Chamberlain；以下内容主要来自 Chamberlain 主持的第二场会话，并补充了来自议题提案讨论和与 Bottomley 的电子邮件交流的一些背景信息。

背景

Bottomley 试图解决的根本问题是，efivarfs 在系统恢复操作后可能无法反映系统上 EFI 变量的正确状态。这是因为在挂起之后，系统上可能启动了其他操作系统，并改变了一些变量。因此，他一直在寻找一个挂接点（hook），以便在系统恢复时添加一个重新同步操作。他有了一个解决方案，虽然有点难看，但他认为其他文件系统可能会受益于拥有某种 API，以便在挂起-恢复周期中提供更好的文件系统一致性（consistency）保证。正如他的提案所指出的：

休眠（hibernate）是一种特别危险的操作，恢复可能会失败，导致完全重启并产生文件系统不一致（inconsistencies）。在很多方面，一次失败的恢复操作就像一次系统崩溃（crash），文件系统已经为此提供了特定的保证。然而，对于这种崩溃，如果文件系统有电源管理钩子，它们可以提前得到预警，并可能使文件系统更整洁，以便最终完全恢复。例如，可以保证即使恢复失败，未提交的数据（uncommitted data）也能得以保留，而这在今天的崩溃场景中是无法保证的。

文件系统冻结和解冻超级块（superblock）的 API 被认为是应该使用的正确钩子，但这个 API 并没有被挂起和恢复操作调用，尽管许多人曾认为它是被调用的。在提案讨论线程中，Bottomley 指出曾有几次尝试在挂起时冻结文件系统，但都因为各种死锁（deadlock）问题而搁浅。Jan Kara 描述了 FUSE（Filesystem in Userspace，用户空间文件系统）文件系统的一个问题；用户空间（user space）需要保持运行，否则写入操作会阻塞（block），因此存在一些需要解决的顺序问题。

在第一场会话中，大家一致认为，尝试按超级块的反向顺序冻结文件系统是有意义的，这样每一层更接近存储层（storage）的文件系统仍然保持活跃，以便能刷写（flush）数据。任何在文件系统被冻结后仍然访问它们的用户空间进程实际上会自行挂起（suspend），并且在所有文件系统都被冻结后，用户空间可以完全挂起。大家普遍认为这会奏效，但这显然需要进行测试，Bottomley 已在大会期间开始着手进行。

第二场会话

Chamberlain 致力于文件系统冻结工作已有几年了。他说，他在大会途中乘坐飞机时还在编写这些补丁（patch），这些补丁他上次发布是在 2023 年，但没能完成。他发布这些补丁部分是为了让参会者为他在LSFMM+BPF 2023 的会话做准备。在上次发布时，存在一些锁问题，他已经绕过了这些问题，他在今年的会话开始时提出了这一点。Christian Brauner 说，这些问题已经解决了；在冻结时 VFS（Virtual Filesystem Switch，虚拟文件系统开关）和块层（block layer）之间存在一些锁反转（locking inversions），但这都已经被理顺了，“据我所知，从这个角度看应该是安全的。”

他说，Chamberlain 的其余补丁都是由 Coccinelle 工具驱动的，并且相当清晰直接。应用这些补丁后，可以开始使用 XFS 文件系统进行测试，然后将它们逐个添加到 ext4 和其他文件系统，当然还需要进行更多测试。大家讨论了冻结文件系统的顺序，包括各种可能的死锁问题，但大多数有问题的用例已经得到解决，或者正在从内核（kernel）中移除。

Chamberlain 说，对这项改变进行自动化测试（Automated testing）会有些困难，因为目前还没有一个真正的测试框架。例如，Fstests（文件系统测试套件）就不测试恢复操作。他说，目前最好的测试方法是使用笔记本电脑，这样可以访问真实的系统挂起和恢复操作。Ted Ts'o 建议测试一个回环文件系统（loopback filesystem），它使用一个文件系统上的文件作为另一个文件系统上的挂载点（mount），这是一种很好的方法来尝试确保冻结操作的顺序得到正确处理。

Lennart Poettering 说，systemd（系统和服务管理器）已经放弃在挂起系统前调用同步系统调用 `= sync() =`，原因是复杂的挂载拓扑（例如经常涉及 NFS）需要太多时间来完成操作。他表示，该项目本来会研究冻结文件系统，但这并非用户空间可以完成的任务，因为存在死锁的可能性。他乐于看到内核来负责所有这些工作。

Chamberlain 回到关于摆脱内核线程冻结器（kthread freezer）的计划（这是他在 2023 年会话的主题）。第一步是移除文件系统对它的使用，这就是他的 Coccinelle 脚本所做的工作，但随后还需要处理 kthread-freezer API 的其他使用者。他说，这个 API 最初是为了文件系统使用而添加的，但内核的其他部分也开始使用它，所以“下一个挑战”将是在整个内核中移除它。

听众中对 kthread freezer 到底是什么有很多困惑。Bottomley 认为它是 `= freeze_task() =` 调用，但没有找到文件系统使用它的任何地方。Chamberlain 说，也许情况已经改变了，但一旦文件系统在挂起期间得到适当冻结，就需要对此进行更多调查。

通过远程连接，Kara 提出了拟议机制的一个潜在问题：未挂载但使用文件作为其存储的回环块设备（loopback block devices）。这些设备可能存在脏数据（dirty data），但当这些数据被刷写时，底层的那个文件系统会被冻结，因为块设备是在文件系统之后冻结的，因此会发生死锁。这种用例被认为足够罕见，至少目前可以忽略。

自那次会话以来，已经发布了几份补丁，其中包括一份来自 Chamberlain 和另一份来自 Brauner，后者整合了 Chamberlain 的补丁。

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

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

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