可以突然移除可拆卸设备（例如 eSATA、USB 驱动器） (只需拔掉插头即可)。
如果分区上有打开的文件句柄，则该分区将不会卸载，即umount即使在驱动器物理分离之后，Linux 命令也将失败。
如果卸载失败，则在重新连接设备时，卸载mount也会失败。因此，您必须找出哪些进程正在使用该驱动器并终止它们或关闭所有句柄。如果两者都无法做到，则必须重新启动该框才能安装驱动器。而且我绝对不能终止使用它的进程。
我没有看到“强制卸载”选项，有一个-f选项，但它仅适用于 NFS。
这听起来很奇怪，Linux 难道不能适应这种用户只需拔出驱动器的情况吗？有人知道如何在 Linux 中妥善处理这种情况吗？
有什么方法可以找出特定分区/设备上打开的文件句柄，或者有选择地刷新并关闭特定设备的所有文件句柄？
注意：该lsof命令在我使用的嵌入式 Linux（busybox）中不可用。
我的嵌入式 Linux 中没有“fuser”。
我尝试了 lazy umount -l。但是，它似乎并不总是有效。例如，我保持文件句柄打开（在设备上的某个文件上使用“tail -f”）。然后我分离一个驱动器，然后执行“umount -l”，它就会卸载。然后我重新连接驱动器并尝试在同一个挂载点上再次挂载它，而 tail 仍在运行。它并不总是有效。有时成功，有时失败。这让我对使用 lazy 选项感到不舒服，如果它使文件系统处于不一致的状态怎么办。我也不确定这个 lazy 选项是否适用于这种情况。
我无法终止打开文件句柄的进程。
似乎如果我将设备安装在 /mnt/abc 上，并且断开驱动器然后重新连接，Linux 似乎会将设备的文件系统重新连接到相同的安装点“/mnt/abc”，而无需我们执行任何卸载或安装。然后，相同的旧打开文件句柄似乎在重新连接后开始工作（至少对于文件读取操作）。这是我的观察。我不确定这是否是预期的行为。但是，这似乎也不能始终如一地工作。
我有一个打开的文件句柄用于读取（“tail -f”），我将其保持打开状态，然后我将其分离并重新连接，然后修改了正在被 tail 的文件，我看到“tail -f”输出随着更改而更新。但是，如果我在设备消失后尝试修改文件（它会按预期给出错误），然后我重新连接，设备的文件系统无法正确地重新连接到相同的挂载点。如果写入文件（当设备不在时），它似乎不起作用。
当突然移除驱动器而没有关闭所有句柄并正确卸载所有分区时，Linux 是否遵循任何标准/一致的行为？
答案1
您可以编写一个 bash 脚本来扫描列出的所有文件描述符/proc（假设您有）并列出/终止进程。
/proc/$m/fd/$n是以符号链接形式呈现的 PID m 的第 n 个文件描述符。busybox确实有 readlink 支持，因此您应该能够自动执行它。
编辑：只是说这本质上是重新实现lsof，但它实际上相当简单。
答案2
您可以使用lsof列出某个目录下打开的文件lsof +D /path/to/mountpoint。
答案3
你有没有尝试过：
umount -l /path/to/mountpoint
fuser -km /path/to/mountpoint
好吧，我之前的建议没有奏效。我知道这可能很愚蠢，但你真的尝试过吗：
umount -f /path/to/mountpoint
根据 Busybox 文档，它应该是强制卸载选项（以 NFS 为例）。
如果这不起作用，您是否尝试过：
eject -s /dev/my-sata-or-usb-device
答案4
当您缺少时，一个快速的解决方案lsof是将
find /proc/*/fd | xargs readlink | grep /mount_pointmount_point 替换为实际的挂载点。这是基于上述 billc.cn 的回答。