c - umount 是否异步释放底层设备？

Question

我有一些代码可以卸载设备上的文件系统，然后使用 DM_DEV_REMOVE ioctl 命令立即从设备映射器中删除设备。

有时，作为压力测试的一部分，我会在以下紧密循环中运行此代码:

1. 创 build 备
2. 在设备上挂载文件系统
3. 卸载文件系统
4. 移除设备

通常，在运行此测试数千次迭代时，我最终会在尝试删除 设备时得到错误号 EBUSY。卸载总是成功的。

我已经尝试搜索这个问题，但我发现的大部分是人们在卸载时遇到 EBUSY 问题，这不是我遇到的问题。

我能找到的最接近帮助的是 man page for dmsetup它讨论了使用 --retry 选项作为 udev 规则在您尝试删除设备时打开设备的解决方法。对我来说不幸的是，当我尝试删除它时，我已经能够确认 udev 没有打开我的设备。

我已经使用 DM_DEV_STATUS 命令检查了我设备的 open_count，我看到的是 open_count 之前始终为 1 umount，当我的测试成功时，它在 umount 之后为 0，而当它失败时，它在 umount 之后为 1。

现在，我试图找出我的问题的根本原因是，“我的资源繁忙失败是否是由 umount 异步释放我的设备引起的，从而造成竞争条件？”。我知道 umount 在实际卸载时应该是同步的，但我找不到任何文档来说明释放/关闭底层设备是否可以异步发生。

而且，如果不是 umount 持有我的设备的打开句柄，还有其他可能的候选人吗？

我的测试在 3.10 内核上运行。

Answer 1

从历史上看，系统调用会阻塞所涉及的进程，直到所有任务完成(write(2) 到 block 设备是第一个主要异常，原因很明显)原因是您需要一个进程完成这项工作并且系统调用涉及的过程是出于这个原因(并且您可以向该用户的帐户收取 cpu 处理费用)

现在，有很多内核线程参与解决非进程相关的问题，umount(2) 系统调用可能是需要一些背景知识的系统调用之一(我认为它不是因为 umount(2) 并不经常发布以证明代码中的更改是合理的)

但是 linux 不是 unix 的后代，所以 umount(2) 可以这样实现。无论如何，我不相信。

umount(2) 系统调用通常会成功，除非文件系统上的 inode 正在使用中。事实并非如此。但是内核可能会参与一些繁重的进程，使其分配一些内核内存(不可交换)并在请求中失败。这可能会导致错误(请注意，这只是一个猜测，我没有在代码中检查过这个，你最好看看 umount(2) 系统调用实现)你无论如何都会得到。

还有另一个问题，如果您以某种方式触及文件系统，它可能会阻止您的卸载过程(或失败)。有一些引用依赖代码使文件系统能够在一致的状态下抵抗电源故障(在 linux 中，这称为 ordered data，在 BSD 系统中称为 software updates，这使得已删除的文件不会在 unlink(2) 之后立即被释放。如果某些数据必须更新，这可能会阻止 umount(2)(或使其失败)文件系统，在进行实际的 umount(2) 调用之前。但是，这不应该是你的情况，正如你所说，你不修改已安装的文件系统。