像 eSATA、USB 驅動器這樣的可拆卸設備可以突然移除（只需拔掉插頭）。
如果分割區上有開啟的檔案句柄，則該分割區將不會卸載，即 Linuxumount命令將失敗，即使在實體分離磁碟機之後也是如此。
如果卸載失敗，則重新連接裝置時mount也會失敗。因此，您必須找出哪些進程正在使用該磁碟機並殺死它們或關閉所有句柄。如果兩者都做不到，則必須重新啟動盒子才能安裝驅動器。我絕對不能殺死使用它的進程。
我沒有看到“強制卸載”選項，有一個-f選項，但它僅適用於 NFS。
這聽起來很奇怪，Linux 不適應用戶簡單地拉動驅動器的這種情況嗎？有誰知道如何在 Linux 中優雅地處理這種情況？
有什麼方法可以找出特定分割區/裝置上開啟的檔案句柄，或僅針對特定裝置選擇性地刷新和關閉所有檔案句柄？
注意：該lsof命令在我使用的嵌入式Linux（busybox）中不可用。
“fuser”在我的嵌入式 Linux 中不可用。
我嘗試了惰性umount -l。然而，它似乎並不能始終如一地發揮作用。例如，我保持文件句柄開啟（在裝置上的某些文件上使用“tail -f”）。然後我分離一個驅動器，然後執行“umount -l”並將其卸載。然後我重新連接驅動器並嘗試將其再次安裝在同一安裝點上，同時尾部仍在運行。它並不能始終如一地發揮作用。有時會成功，有時則不會。這讓我在使用惰性選項時感到不舒服，如果它使檔案系統處於不一致的狀態呢？而且我也不確定這個惰性選項是否適用於這種情況。
我無法終止開啟文件句柄的進程。
似乎如果我已將設備安裝在/mnt/abc 上，並且如果我斷開驅動器連接然後重新連接，Linux 似乎會將設備的文件系統重新附加到同一安裝點“/mnt/abc”，而無需我們執行任何操作卸載或安裝。然後，相同的舊開啟檔案句柄似乎在重新附加後開始工作（至少對於檔案讀取操作）。這是我的觀察。我不確定這是否是預期的行為。
我有一個打開的文件句柄用於讀取（“tail -f”），我將其保持打開狀態，然後我分離並重新附加，然後修改了被尾隨的文件，我看到“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 替換為實際的安裝點。這是基於bilc.cn上面的回答。