it-swarm-ja.com

「デバイスまたはリソースがビジー」のためにrmdirが失敗しました

「デバイスまたはリソースがビジー」などの同様の問題が多数あります。しかし、私の問題は彼らとは異なると思います。

Mount --bindを使用してディレクトリをバインドします

mount --bind /tmp/Origin /tmp/mount

そして、正常にアンマウントできます

umount /tmp/mount

そして、一度にrmを呼び出すと

rm -rf /tmp/mount

エラーDevice or resource busyが発生する可能性があります。 2〜3秒待ってからrmを呼び出すと、成功する可能性があります。

したがって、この動作は非常に奇妙です。使ってみます

lsof +D /tmp/mount

何も見えませんでした。

また、fuser -vm /tmp/mountを使用していますが、このフォルダーを保持しているプロセスはありません。

/proc/mountsの前とumount /tmp/mountの後のumount /tmp/mountを比較します。 /tmp/mountは既に削除されています。

stat /proc/mountsの前とumount /tmp/mountの後のumount /tmp/mountを比較します。 iノードも異なります。つまり、/tmp/mountはすでに完全に削除されています。

sync && echo 2 > /proc/sys/vm/drop_cachesを呼び出してファイルキャッシュを削除しようとしても、まだ機能しません。

これをUbuntu 14.04とCentOS 6.6の両方で試します。同じ結果が得られます。

5
haosdent

@ g-vの回答ありがとうございます。しかし、結果は別の問題であることがわかりました。プロセスを分岐するときにCLONE_NEWNSフラグを使用します。詳細は CLONE_NEWNSフラグ および MESOS-3349 Device busy bug にあります。

短いWordでは、親プロセスにマウントします。そして、CLONE_NEWNSのために、子プロセスでアンマウントしますが、親プロセスによって処理されるマウントポイントがまだ存在します。したがって、rmdirを呼び出すとEBUSYエラーコードが返されます。

上記の問題を回避するには、共有マウントまたはスレーブマウントを使用できます。詳細は LWN 159092 にあります。

1
haosdent

共有フォルダをVMにマウントし、アンマウント後にディレクトリを削除し、ソリューションを共有したいだけなので、このような問題に直面しました。

  1. アンマウントパス

    Sudo umount /your_path
    
  2. / etc/fstabのmoutパスを削除します

    Sudo nano /etc/fstab
    
  3. リブート

    Sudo reboot
    
  4. ディレクトリを削除

    Sudo rm -rf /your_path
    
8
thyahan

私の経験では、次の操作は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_については、 here を参照してください:

これは非破壊的な操作であり、ダーティオブジェクトを解放しません。

したがって、コマンドの直後に、データはまだ書き込みのためにキューに入れられ、アンマウントはまだ完了していません。


更新

ただし、非同期のアンマウントが実行されている場合、カーネルはmounted deviceに対する操作に対してEBUSYを返しますが、に対しては返しません。マウントポイント

したがって、上記のケースできなかったが問題の原因になります:P


PS。

実際、manページにsync(8)がLinuxで同期していないと書かれている理由がわかりません。 sync(2) を呼び出します。

標準仕様(例:POSIX.1-2001)によれば、sync()は書き込みをスケジュールしますが、実際の書き込みが完了する前に戻る場合があります。ただし、バージョン1.3.20以降Linuxは実際に待機します。(これでもデータの整合性は保証されません。最新のディスクには大きなキャッシュがあります。)

4
gavv