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

Question

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

在@cas 的回答中：

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

@frostschutz 的评论：

umount --lazy是不安全的，也不能变得安全。[...]

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

你应该完全避免使用umount -l。只需杀死所有正在使用的进程，/tmp/mountpoint然后不带选项 umount 即可-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使用可移动磁盘，则您处于不确定状态：您无法确定所有待处理数据都已写入磁盘。

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

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

• 设备将获得一个递增的设备名称，即/dev/sdb变为/dev/sdc。内核日志消息仍可能是指/dev/sdb，即使该设备不再作为下的文件/dev。（我知道解决此问题的唯一方法是重新启动。）

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

systemd 陷阱

• 似乎MNT_DETACH是由于使用x-systemd.mount-timeout=in/etc/fstab或 using TimeoutIdleSec=in a Automount file导致的延迟卸载。

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