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

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

在@cas的回答中：

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

@frostschutz的评论：

umount --lazy是不安全的，不能保证安全。[...]

这util-linux 通过Ruediger迈耶评论：

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

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

有没有办法使它安全？

懒惰的卸载会创建薛定ding的猫坐骑

• 您不知道设备是否已真正卸载
• 在某些情况下，“卸载”文件系统仍可访问
• 在某些情况下无法访问“卸载”文件系统

有一种错误的安全感：似乎文件系统已被卸载，但实际上它只是从文件名称空间/层次结构中隐藏了。

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

这意味着，如果您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使用可移动磁盘，那么您将处于困境：您无法确定所有待处理的数据都已写入磁盘。

在a之后，您可以做的最好的事情umount -l是确保完成所有写入并防止将来写入，但是您仍然不能保证已卸载它。

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

• 设备将获得递增的设备名称，即/dev/sdb成为/dev/sdc。/dev/sdb即使该设备不再以文件形式存在于该内核日志消息中，也仍然可以引用/dev。（我知道解决此问题的唯一方法是重新启动。）

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

systemd 陷阱

• 看来MNT_DETACH是由于在自动挂载文件x-systemd.mount-timeout=中/etc/fstab或TimeoutIdleSec=在自动挂载文件中使用造成的延迟卸载或延迟。

• 避免使用以上systemd选项，尤其是在使用时btrfs。我从痛苦的经验中学到了（请参阅上面的btrfs参考）。