Was ist los 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 Dateisystemfehlerproblem erkannt haben. Leider ist die einzige sichere Maßnahme zur Behebung der Beschädigung das Abhängen der Platte und das Ausführen e2fsckim Dateisystem. (Technisch gesehen benötigen Sie diese -fOption nicht, da das Dateisystem bereits Probleme erkannt hat und das Dateisystem als in Schwierigkeiten befindlich markiert hat. Wenn Sie es ausführen e2fsck, wird ein vollständiger Scan durchgeführt, um diese Probleme zu beheben, und Sie benötigen dies nicht die -fOption, eine Prüfung zu erzwingen.)
Berichte über Dateisystembeschädigung
Sie sollten auch die Berichte über die Beschädigung des Dateisystems anzeigen können, indem Sie die Kernelprotokolle anzeigen. (zB durch Ausführen dmesgoder Durchsuchen von /var/log/kern.logoder wo auch immer syslogoder journaldkonfiguriert wurde, um Kernel-Nachrichten zu protokollieren. Sie sollten Meldungen anzeigen, die beginnen EXT4-fs error (device sdXX). 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 Inkonsistenzen im Dateisystem 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 gefunden. Mit der Fehlerfunktion und der Zeile # können Sie genau feststellen, welcher Teil des Kernelcodes das Problem gefunden hat. Die Inode # 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 Dies zeigt an, wann der Kernel eine Inkonsistenz des Dateisystems festgestellt hat. Die großen Deltas zwischen den beiden Zeiten bedeuten, dass jemand seine Kernel-Nachrichten nicht gescannt hat. Das liegt daran, dass ext4 alle 24 Stunden Warnmeldungen protokolliert, dass ein Dateisystem mit Fehlern vorliegt. Diese Kernelmeldungen werden wie folgt aussehen:
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 Uhrzeit im Kernel gibt die Anzahl der Sekunden seit dem 1. Januar 1970 um Mitternacht UTC an. Sie können dies mithilfe des Datumsbefehls in eine für Menschen besser lesbare Zeit konvertieren. Beispiel:
% date -d @1441536566 Sun Sep 6 06:49:26 EDT 2015 Was ist zu tun, wenn Sie feststellen, dass Ihr Dateisystem beschädigt ist?
Sie möchten wirklich nicht mit Dateisysteminkonsistenzen laufen, da dies zu mehr Datenverlust führen kann. Es ist wirklich eine gute Idee, auf diese Berichte zuzugreifen, ggf. Ausfallzeiten zu planen und sie so schnell wie möglich zu beheben.
Warum wurde e2fsckbeanstandet, dass das Gerät verwendet wurde, nachdem ich es abmontiert habe?
Zum Schluss noch eine Antwort auf Ihre Frage: "Ich bin fscknach dem Abmelden gelaufen und erhalte folgende Fehlermeldung: /dev/sdb1 is in use.Irgendwelche Ideen?" Dies ist wahrscheinlich darauf zurückzuführen, dass Sie einen oder mehrere Prozesse in einem alternativen Mount-Namespace haben und diese Prozesse noch /dev/sdb1in diesem Mount- Namensraum eingehängt sind. Vielleicht möchten Sie es versuchen:
grep /dev/sdb1 /proc/*/mounts Wenn Sie feststellen, dass Prozesse in einem alternativen Mount-Namespace ausgeführt werden, ist es am einfachsten, diese Prozesse zu beenden und erneut zu starten. (Es handelt sich wahrscheinlich um Daemon-Prozesse.) Wenn der letzte Prozess, der einen Mount-Namespace verwendet, beendet wird, wird der Mount-Namensraum nicht mehr angezeigt. Und sobald keine Mount-Namespaces mehr bereitgestellt wurden /dev/sdb1, wird sie wirklich für echte Unmounten freigegeben.
Die Art und Weise darüber nachzudenken ist, dass sich umountdas so anhört unlink. Wenn Sie eine Datei mit mehreren Hardlinks haben, wird der Speicherplatz erst freigegeben, wenn der letzte Hardlink gelöscht wird. Wenn mehrere Namespaces aktiv sind, fungiert jeder Namespace als "harte Verbindung" zu dem betreffenden Mount. Das einfache Aufheben der Bereitstellung des Dateisystems im Standard-Mount-Namespace ist daher nicht hilfreich, wenn ein Prozess den Standard-Mount-Namespace durchlaufen hat und selbst ausgeführt wird und möglicherweise einige untergeordnete Prozesse in dieser Copy-on-Write-Kopie des übergeordneten Mount-Namensraums.