LWN：移除kthread freezer！

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

Removing the kthread freezer

By Jake Edge
June 23, 2023
LSFMM+BPF
ChatGPT assisted translation
https://lwn.net/Articles/935602/

2023 年 Linux 存储、文件系统、内存管理和 BPF 峰会的最后一天，由 Luis Chamberlain（他还主持了第二天的全体会议）主持了三个独立的会议。其中之一是关于 kthread-freezer-removal 工作的文件系统会议。kthread freezer 旨在帮助文件系统冻结其状态，以便 suspend 或休眠（hibernate）整个系统，但至少从 2015 年以来，就一直有人计划移除这个功能。一年后的情况也没有多大改变，2018 年的 LSFMM 会议上，Chamberlain 接手了 Jiri Kosina 的移除工作；今年，Chamberlain 回来继续推动其进展。

他开始时说，让文件系统在准备 suspend 系统之前冻结文件系统状态，在 Linux 上多年来一直存在问题，这可能会让一些人感到惊讶。目前没有统一的机制来冻结文件系统，如果有大量的 I/O 操作正在进行，那么在 resume 时可能会导致系统 hang，这不会是用户想要的结果。

问题出在 kthread-freezer API 上，该 API 用来帮助在 suspend 操作期间停止进行中的 I/O，但它的语义有些不严谨，使用方式也比较随意。上次在 LSFMM 讨论 kthread-freezer 问题时，控制组（cgroup）冻结在内核中就出现了问题，但他想知道现在的情况如何。Aleksa Sarai 表示已经 fix 了这个问题，但另一位与会者补充说，这需要一个新的 cgroup 文件系统。Chamberlain 表示，在冻结过程中还存在与自动挂载工具（automounter）冲突的问题，但会场上没有人似乎了解这方面的情况；“那么我们都需要记住这一点”。

[Luis Chamberlain]

有一些时序问题需要解决。最终可能需要构建一个文件系统 superblock 的有向无环图（DAG, directed acyclic graph），以便按正确顺序进行冻结和解冻操作。他说，Al Viro 曾感叹原来实现的 LOOP_CHANGE_FD ioctl()命令，从而 Fedora 的 live 安装方式可以直接跳转到新安装的文件系统；但这在遍历 superblock 时破坏了预期的顺序，因此这些系统的 suspend 可能会出现问题。RAID 也可能引入时序方面的异常。人们假设在遍历 superblock 时，正向和反向迭代的次序是一致的；这很可能在大多数使用笔记本电脑和移动设备的使用场景中是可行的，他们是主要的在进行 suspend 操作的用户。

Chamberlain 想知道是否需要一种机制来通知用户空间应用程序即将进行 suspend 操作，以便给它们一些时间来安静下来。Ted Ts'o 说 Windows 中已经有这种通知机制，但应用程序需要花一定的时间才能安静下来；如果这个过程无法完成，suspend 操作将继续进行而不管它们。实现这种通知并不难，“那只要使用 D-Bus 或类似的东西做管道就行”。

处理 network block 设备是另一个问题领域，Ts'o 说这个问题已经被提出 8 年了，但是“每个人都说‘是的，这很难’，然后都悄悄退后了”。David Howells 指出，FUSE 文件系统也增加了这个问题的复杂性，因为它既有内核空间的部分，也有用户空间的部分需要被冻结。Amir Goldstein 指出，checkpoint/restore 的开发者已经在处理这些复杂情况，这可能成为一个模型。

Lennart Poettering 说，systemd 已经有了一套基础设施用于进行用户空间的通知。如果应用程序希望接收通知，它们可以从 systemd 中获取，并在需要时有几秒钟的反应时间。他指出，目前的 suspend-then-hibernate 顺序是在 suspend 模式下经过一段时间后唤醒所有用户空间的工作，然后进行 hibernate，这个做法是“很愚蠢的”。因此，目前正在进行的一个开发工作，就是使用 cgroup freezer 把除了跟切换到 hibernate 模式的小部分内容之外的所有其他用户空间工作都保持冻结状态。Jan Kara 表示，内核仍然需要对文件系统进行解冻，以便让监测（overseer）进程可以检查电池状态等。

Chamberlain 表示，听起来用户空间方面的问题在很大程度上已经解决了。他想讨论在文件系统中移除 kthread-freezer 调用后的下一步。他会使用 Coccinelle 语义 patch 来进行这个移除操作。他最新的 patch 是用于替代 kthread freezer API 的自动内核 freeze 和 resume 代码的核心部分；之前今年 1 月份的 RFC patch set 使用 Coccinelle 规则移除了十几个文件系统中的相关代码。

他怀疑是否有必要继续在内核的其他部分中来移除对这个 API 的使用。他说，该 API 是为了允许文件系统停止进行中的 I/O 操作，所以在其他地方使用的话可能是错误的。Jeff Layton 说该 API 在 NFS 中被使用，他并不认为是正确的做法，所以他打算提供帮助从 NFS 中移除 kthread freezer。Sarai 说 cgroup v1 仍然使用 kthread freezer，他不知道为什么没有与 cgroup v2 进行类似的更改；在完全移除 API 之前，需要讨论一下。Howells 指出，所有网络文件系统都会存在 Layton 关注的一些问题。Chamberlain 总结说，可以逐步进行这个移除工作，挨个处理文件系统和子系统。

请注意，此会议的视频名称被错误标记成了 Chamberlain 主持的 iomap-conversion-status 会议，其实该会议是紧随其后的，并且不出意外，该会议的视频标题为“Removal of kthread freezer next steps”（移除 kthread freezer 的下一步）。

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

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

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