LWN：用户空间块设备驱动的崩溃恢复！

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

Crash recovery for user-space block drivers

By Jonathan Corbet
August 29, 2022
DeepL assisted translation
https://lwn.net/Articles/906097/

在 6.0 的合并窗口期，内核合入了一个新的用户空间块设备驱动机制（user-space block driver mechanism）进入内核。这个被称为 "ublk" 的子系统，使用了 io_uring 与用户空间驱动进行通信，从而得到了不少令人印象深刻的性能得分。Ublk 有很多有趣的潜在价值，但不确定它的使用场景是什么。最近发布的 ublk 的 crash-recovery 机制让人明白确实是有真实用例的。

如果一个内核内的块设备驱动崩溃了，很可能会导致整个内核都无法正常运行了。如果把这些驱动放到用户空间，那么理论上可以得到一个更健壮的系统，因为内核现在可以在驱动 crash 后仍能正常运行了。但是，在 6.0 内核中的 ublk 中，驱动 crash 会导致相关设备消失，并且所有未完成的 I/O 请求都会失败。从用户的角度来看，这个结果可能跟系统完全崩溃基本上没有什么差别了。正如 patch 作者 Ziyang Zhang 在说明邮件中指出的，一些用户可能会对这种结果感到失望：

这在实践中并不是一个好选择，因为用户并不希望出现请求被中途中止（abort）、I/O 错误、设备被释放掉等情况。他们可能希望有一个恢复机制从而不会有中止请求，也不会有 I/O 错误。总之，用户只是希望一切照旧。

这组 patch 的目标就是要实现这个愿望。

实现 crash recovery 恢复的用户空间 block driver 应该用新的 UBLK_F_USER_RECOVERY 标志来对相应的 ublk 设备进行配置。此外还有一个可选 flag UBLK_F_USER_RECOVERY_REISSUE，它可以控制恢复的方式，下面会有详细介绍。在配置好之后，正常的驱动操作不需要进行任何改动。

如果一个具有恢复能力的 ublk 驱动崩溃了，内核就会停止相关的 I/O 请求队列，从而避免增加未来的请求，然后耐心地等待一个新的驱动进程出现。这里可能永远都等不到，不过既然一个驱动程序声称能够进行恢复，那么内核就期望它能够自己恢复自己。驱动程序 crash 时没有通知机制；用户空间需要自己发现出现了意外结束的情况，并且启动一个新的驱动程序。

新的驱动进程将 connect 到 ublk 子系统，并发出 START_USER_RECOVERY 命令。这会让 ublk 来验证旧驱动是否真的消失的，并进行相关清理，包括处理所有未处理的 I/O 请求。任何在 crash 后出现的、未被老驱动接受的请求都可以直接重新在新驱动中排队等待处理。不过，那些已经被 accept 过的请求可能需要更小心地处理，因为内核不知道它们是否真的被执行过。

显然，有些 ublk 后端代码是无法正确地处理重复写入的；在这种情况下必须避免要避免重复再写入一次。这就是 UBLK_F_USER_RECOVERY_REISSUE 标志的作用；如果有这个 flag，那么所有未处理的请求将被重新发出来。否则的话，那些已经被驱动接收了的 request，如果没有走到 completion 状态的话，就只能返回错误状态告知失败。这种情况甚至会出现在 read request 上，人们通常会认为 read request 重复处理的话是没有什么坏处的。

在开始恢复流程后，新的驱动程序应该重新连接每个设备，并在每个设备上发出一个新的 FETCH_REQ 命令，从而启用 I/O request 的处理流程。等所有的设备都被设置好之后，END_USER_RECOVERY 命令将重新启动 request queue，让一切重新开始。运气好的话，用户甚至可能不会注意到 block 驱动程序崩溃并被替换过了。

ublk 子系统是从 Red Hat 创造出来的，其中只包括一个简单的 file-backed 驱动程序，基本上是复制了 loop 驱动程序来作为一个例子进行展示。当时，模糊地提到了这个子系统中的各种使用场景，但不清楚它出了给出 demo 之外可以如何（或是否）使用的。它看起来有点像一个等待问题出现的有趣的解决方案。

在 ublk 被合并的几周后，来自另一个公司（阿里巴巴）的这种恢复机制就出现了，这表明存在更复杂的使用场景了，而且 ublk 确实已经在积极使用中。这种恢复机制往往都是在确实看到一些真实需求之后才会被开发出来。估计这些真实世界的使用场景很快就能被人们发现（通过代码），这样世界上的其他人也能从这项工作中受益。

这些信息同样在另一方面也是有价值的，那就是可能会对 Linux 在未来几年的发展方向提供一些线索。目前有不少努力在模糊内核任务和用户空间处理任务之间的边界，并且看起来没有放缓的迹象。在未来估计会看到更多类似 ublk 的机制。如果能知道这些变动将把我们带向何方，那会是非常有趣的事情，也希望能证明这并不是一个把所有开发工作都转移到专有的用户空间驱动的世界。

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

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

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