为什么惰性 MNT_DETACH 或 `umount -l` 不安全/危险？

Question

我读过一些umount -l不安全的地方：

在 @cas 的回答中：

如果您关心何时可以安全拔出外部驱动器，请不要使用umount的选项--lazy

@frostschutz 的评论：

umount --lazy不安全，也无法使其安全。 [...]

这util-linux 鲁迪格·迈耶评论：

您应该umount -l完全避免使用。只需杀死所有正在使用的进程/tmp/mountpoint，然后不带选项卸载即可-l。

为什么umount -l不安全/危险？

有办法保证安全吗？

Answer 1

惰性卸载会创建一个薛定谔的猫山

• 您无法知道设备是否实际上已卸载
• “已卸载”的文件系统遗迹在某些情况下可以访问
• “已卸载”的文件系统不是在某些情况下可以访问

有一个错误的安全感：看起来文件系统已被卸载，但实际上它只是从文件命名空间/层次结构中隐藏。

• 进程仍然可以通过打开的文件描述符进行写入
• 新的或现有的文件可以通过相对路径名由挂载点内具有工作目录的进程打开以进行写入

这意味着，如果您umount -l /media/hdd将不再能够访问/media/hdd/dir/file（绝对路径名），但如果您有一个带有工作目录的进程，/media/hdd它仍然能够创建可以读/写./dir/file（相对路径名）的新进程。

如果您尝试卸载设备，您会看到一条令人困惑的消息：

# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted

这使得该设备看起来像是未计数的，但有仍然可以是写入磁盘的进程。

由于有各种可能导致 umount 阻塞的非明显情况，即使lsof +f -- /dev/device什么也没有显示，文件系统可能仍然没有被卸载。

您永远不会知道文件系统是否真正卸载。没有办法知道。

可卸除的设备

如果你这样做umount -l可移动磁盘，那么您就陷入了困境：您无法确定所有待处理的数据都已写入磁盘。

事后你能做的最好的事umount -l就是确保所有写入完成并防止将来写入，但你仍然不能保证它已经被卸载。

对于可移动设备，如果设备未正确卸载，下次插入时可能会出现奇怪的行为：

• 该设备将获得一个递增的设备名称，即/dev/sdb变为/dev/sdc。即使该/dev/sdb设备不再作为. /dev（我知道解决此问题的唯一方法是重新启动。）

• 可能会导致 btrfs 损坏。 btrfs 期望一次仅存在一个具有给定 UUID 的文件系统。内核仍然会在幻象设备和新设备上看到相同的 UUID。 （我必须重建我的 btrfs 备份硬盘）。

systemd陷阱

• 看来是懒惰卸载或MNT_DETACH是由 using x-systemd.mount-timeout=in/etc/fstab或 using TimeoutIdleSec=in 自动挂载文件引起的。

• 避免使用上述systemd选项，尤其是使用btrfs。我从痛苦的经历中吸取了教训（请参阅上面的 btrfs 参考）。