Was ist mit der Fehlermeldung "Struktur muss gelöscht werden"?
Der Fehler "Struktur muss gelöscht werden" ist der Fehler, den Dateisysteme (insbesondere ext4 und xfs) zurückgeben, wenn sie ein Problem mit der Beschädigung des Dateisystems festgestellt haben. Unglücklicherweise ist die einzige sichere Maßnahme, um die Beschädigung zu beheben, die Bereitstellung der Festplatte aufzuheben und sie e2fsckauf dem Dateisystem auszuführen. (Technisch gesehen benötigen Sie diese -fOption nicht, da das Dateisystem bereits Probleme erkannt und das Dateisystem als fehlerhaft markiert hat. Wenn Sie es also ausführen e2fsck, wird ein vollständiger Scan durchgeführt, um diese Probleme zu beheben. Dies ist nicht erforderlich die -fOption, einen Scheck zu erzwingen.)
Berichte über Dateisystembeschädigungen
Sie sollten auch in der Lage sein, die Berichte über Dateisystembeschädigungen in den Kernel-Protokollen anzuzeigen. (z. B. durch Ausführen dmesgoder Anzeigen von /var/log/kern.logoder überall dort, wo Ihr syslogoder journaldkonfiguriert wurde, um Kernelnachrichten zu protokollieren. Es sollten Nachrichten angezeigt werden, die beginnen EXT4-fs error (device sdXX). Zum Beispiel:
EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136
Sie können Hinweise auf Fehler auch dumpe2fs -him Dateisystem anzeigen . Interessensgebiete:
FS Error count: 25
Dies bedeutet, dass der Kernel 25 Mal Dateisysteminkonsistenzen gefunden hat.
First error time: Thu Jan 1 12:19:59 2015
First error function: ext4_ext_find_extent
First error line #: 400
First error inode #: 95223833
First error block #: 0
Der erste Fehler wurde am 1. Januar 2015 zum angegebenen Zeitpunkt festgestellt. Anhand der Fehlerfunktion und der Zeilennummer können Sie genau feststellen, an welchem Teil des Kernel-Codes das Problem aufgetreten ist. Die Inode-Nr. Gibt an, welcher Inode an der Inkonsistenz des Dateisystems beteiligt war.
Last error time: Wed Feb 4 11:57:05 2015
Last error function: ext4_ext_find_extent
Last error line #: 400
Last error inode #: 95223833
Last error block #: 0
Hier erfahren Sie, wann der Kernel zuletzt eine Dateisysteminkonsistenz festgestellt hat. Die großen Deltas zwischen den beiden Zeiten bedeuten, dass jemand seine Kernelnachrichten nicht gescannt hat. Das liegt daran, dass ext4 alle 24 Stunden Warnmeldungen protokolliert, dass es ein Dateisystem mit Beschädigungen gibt. Diese Kernelmeldungen sehen dann folgendermaßen aus:
EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550
Hinweis: Die Zeit in den Kernelnachrichten ist die Anzahl der Sekunden seit dem 1. Januar 1970, Mitternacht UTC. Sie können dies mit dem Befehl date in eine besser lesbare Zeit umwandeln. Beispiel:
% date -d @1441536566
Sun Sep 6 06:49:26 EDT 2015
Was tun, wenn Sie feststellen, dass Ihr Dateisystem beschädigt ist?
Sie möchten wirklich nicht mit Inkonsistenzen im Dateisystem arbeiten, da dies zu mehr Datenverlust führen kann. Es ist wirklich eine gute Idee, auf diese Berichte zuzugreifen, gegebenenfalls Ausfallzeiten zu planen und sie so schnell wie möglich zu beheben.
Warum habe e2fsckich mich beschwert, dass das Gerät verwendet wurde, nachdem ich es abmontiert habe?
Zum Schluss als Antwort auf Ihre Frage: "Ich bin fscknach dem Aushängen gelaufen und erhalte folgende Fehlermeldung: /dev/sdb1 is in use.Irgendwelche Ideen?" Dies liegt wahrscheinlich daran, dass Sie einen oder mehrere Prozesse in einem alternativen Mount-Namespace haben und diese Prozesse immer noch /dev/sdb1in diesem Mount- Namespace gemountet sind. Vielleicht möchten Sie versuchen:
grep /dev/sdb1 /proc/*/mounts
Wenn Sie Prozesse finden, die in einem alternativen Mount-Namespace ausgeführt werden, müssen Sie diese Prozesse am einfachsten beenden und neu starten. (Es handelt sich wahrscheinlich um Daemon-Prozesse.) Wenn der letzte Prozess, der einen Mount-Namespace verwendet, beendet wird, verschwindet der Mount-Namespace. Und sobald es keine Mount-Namespaces mehr gibt, die /dev/sdb1gemountet wurden, wird das Mounten wirklich aufgehoben.
Die Art, darüber nachzudenken, ist, dass man sich so umountverhält unlink. Wenn Sie eine Datei mit mehreren Hardlinks haben, wird der Speicherplatz nur freigegeben, wenn der letzte Hardlink gelöscht wird. Wenn Sie mehrere Namespaces aktiv haben, fungiert jeder Namespace als "harte Verbindung" zum fraglichen Mount. Das bloße Abmelden des Dateisystems im Standard-Mount-Namespace hilft also nicht, wenn ein Prozess den Standard-Mount-Namespace gespalten hat und sich selbst und möglicherweise einige untergeordnete Prozesse in dieser Kopie des übergeordneten Mount-Namespace ausführen.
fsck -f?