VM に共有フォルダーをマウントし、アンマウント後にディレクトリを削除したいので、ソリューションを共有したいだけなので、このような問題に直面しました。
<オール>アンマウント パス
sudo umount /your_path
/etc/fstab の mout パスを削除
sudo nano /etc/fstab
再起動
sudo reboot
ディレクトリを削除
sudo rm -rf /your_path
@g-v 回答ありがとうございます。しかし、結果は別の問題であることがわかりました。プロセスを fork するときに CLONE_NEWNS フラグを使用します。詳細については、CLONE_NEWNS フラグと MESOS-3349 Device busy bug を参照してください
簡単に言えば、親プロセスにマウントします。そして、子プロセスで umount を実行すると、CLONE_NEWNS のために、親プロセスによって処理されたマウント ポイントがまだ存在します。そのため、rmdir を呼び出すと、EBUSY エラー コードが返されます。
上記の問題を回避するには、共有マウントまたはスレーブ マウントを使用できます。詳細は LWN 159092 に記載されています
私の経験では、次の操作は Linux では非同期です:
- ファイルを閉じています。
close()の直後 リターン、umount()EBUSYを返す場合があります 非同期リリースを実行している間。ここでの議論を参照してください:ページ 1、ページ 2。 - ファイルシステムをアンマウントしています。すべてのデータがディスクに書き込まれるまで、マウントされたデバイスはビジー状態になる可能性があります。
私も sync && echo 2 > /proc/sys/vm/drop_caches と呼んでいます ファイル キャッシュを削除しようとしても、まだ機能しません。
sync(8) を参照 :
Linux では、sync 書き込みのためにダーティ ブロックをスケジュールすることのみが保証されます。すべてのブロックが最終的に書き込まれるまで、実際には少し時間がかかる場合があります。 reboot(8) と halt(8) コマンドは sync(2) を呼び出した後、数秒間スリープすることでこれを考慮します .
/proc/sys/vm/drop_caches について 、こちらをご覧ください:
これは非破壊的な操作であり、ダーティ オブジェクトは解放されません。
したがって、コマンドの直後に、データがまだ書き込みのためにキューに入れられていて、アンマウントがまだ完了していない可能性があります。
更新
ただし、非同期アンマウントが実行中の場合、カーネルは EBUSY を返します。 マウントされたデバイスでの操作用 、ただしマウントポイントは対象外 .
したがって、上記のケースはできません あなたの問題の理由になります:P
追記
実際、man ページに sync(8) と記載されている理由がわかりません Linux では同期ではありません。 sync(2) を呼び出します これは次のように述べています:
標準仕様 (POSIX.1-2001 など) によると、sync() 書き込みをスケジュールしますが、実際の書き込みが完了する前に戻る場合があります。ただし、バージョン 1.3.20 以降、Linux は実際に待機します。 (これでもデータの整合性は保証されません。最新のディスクには大きなキャッシュがあります。)