it-swarm.com.de

rmdir schlug wegen "Gerät oder Ressource beschäftigt" fehl

es gibt viele ähnliche Probleme wie "Gerät oder Ressource beschäftigt". Aber ich denke, mein Problem ist bei ihnen anders.

Ich benutze mount --bind, um ein Verzeichnis zu binden

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

und konnte dann erfolgreich umounten

umount /tmp/mount

Und wenn ich dann gleich rm anrufe

rm -rf /tmp/mount

Ich könnte einen Fehler Device or resource busy bekommen. Wenn ich 2 bis 3 Sekunden warte und dann rm anrufe, könnte dies erfolgreich sein.

Also ist dieses Verhalten hier sehr seltsam. Ich versuche es zu benutzen 

lsof +D /tmp/mount

konnte nichts sehen.

Ich benutze auch fuser -vm /tmp/mount, konnte keinen Prozess sehen, der diesen Ordner hält.

Ich vergleiche den /proc/mounts vor umount /tmp/mount und nach umount /tmp/mount. /tmp/mount wurde bereits entfernt.

Ich vergleiche den stat /proc/mounts vor umount /tmp/mount und nach umount /tmp/mount. Der Inode ist auch anders, dh /tmp/mount wurde bereits vollständig entfernt.

Selbst wenn ich sync && echo 2 > /proc/sys/vm/drop_caches anrufe und versuche, Datei-Caches zu löschen, funktioniert es trotzdem nicht.

Ich versuche dies in Ubuntu 14.04 und CentOS 6.6. Sie haben die gleichen Ergebnisse.

4
haosdent

Vielen Dank für die Antwort von @ g-v. Aber ich fand das Ergebnis ein weiteres Problem. Wir verwenden das CLONE_NEWNS-Flag, wenn Sie einen Prozess verbinden. Weitere Details finden Sie in CLONE_NEWNS-Flag und MESOS-3349 Fehler beim Besetzen des Geräts

In einem kurzen Wort mounten wir im übergeordneten Prozess. Und dann inount, umount in untergeordnetem Prozess, weil CLONE_NEWNS noch der Mount-Punkt vorhanden ist, der vom übergeordneten Prozess behandelt wird. Wenn also rmdir aufgerufen wurde, erhielt EBUSY-Fehlercode.

Um die oben genannten Probleme zu vermeiden, können Sie Shared Mount oder Slave Mount verwenden. Weitere Details finden Sie in LWN 159092

1
haosdent

Ich hatte ein Problem wie dieses, weil ich einen freigegebenen Ordner in VM mounte und das Verzeichnis nach dem Aufheben der Bereitstellung entfernen möchte und nur meine Lösung freigeben möchte.

  1. unmount path

    Sudo umount /your_path
    
  2. entferne den Pfad in/etc/fstab

    Sudo nano /etc/fstab
    
  3. neustart

    Sudo reboot
    
  4. verzeichnis entfernen

    Sudo rm -rf /your_path
    
7
thyahan

Nach meiner Erfahrung sind die folgenden Vorgänge unter Linux asynchron:

  • Datei schließen Unmittelbar nach der Rückkehr von close() kann umount()EBUSY zurückgeben, während die asynchrone Freigabe ausgeführt wird. Siehe Diskussion hier: Seite 1 , Seite 2 .
  • Dateisystem ummontieren. Das bereitgestellte Gerät ist möglicherweise ausgelastet, bis alle Daten auf die Festplatte geschrieben wurden.

Selbst wenn ich sync && echo 2 > /proc/sys/vm/drop_caches anrufe und versuche, Datei-Caches zu löschen, funktioniert es immer noch nicht.

Siehe sync(8) :

Unter Linux wird garantiert, dass sync nur die fehlerhaften Blöcke für das Schreiben plant. Es kann tatsächlich eine kurze Zeit dauern, bis alle Blöcke endgültig geschrieben sind. Die Befehle reboot(8) und halt(8) berücksichtigen dies, indem sie nach dem Aufruf von sync(2) einige Sekunden lang im Ruhezustand sind.

Wie /proc/sys/vm/drop_caches, siehe hier :

Dies ist ein zerstörungsfreier Vorgang, der keine schmutzigen Objekte freigibt.

Unmittelbar nach dem Befehl stehen die Daten möglicherweise noch zum Schreiben in der Warteschlange und das Umounting ist noch nicht abgeschlossen.


Update

Wenn jedoch asynchrones Umounting ausgeführt wird, gibt der Kernel EBUSY für Vorgänge an bereitgestellten Geräten zurück, nicht jedoch für Einhängepunkt.

Die Fälle über konnten nicht könnten der Grund für Ihr Problem sein: P


PS.

Eigentlich verstehe ich nicht, warum die Manpage besagt, dass sync(8) in Linux nicht synchron ist. Es ruft sync(2) auf, das besagt:

Gemäß der Standardspezifikation (z. B. POSIX.1-2001) plant sync() die Schreibvorgänge, kann jedoch zurückkehren, bevor das eigentliche Schreiben abgeschlossen ist. Seit Version 1.3.20 jedoch Linux wartet tatsächlich. (Dies garantiert immer noch keine Datenintegrität: Moderne Festplatten haben große Caches.)

4
gavv