Wir haben ein BBB-basiertes Custom-Board mit 256 MB RAM und 4 GB oder eMMC. Wir verwenden Linux-3.12 und auf eMMC haben wir ext4-Partitionen.
Ich schreibe ein Skript, das regelmäßig ausgeführt wird und nach Dateisystemfehlern sucht. Wenn Partitionen nicht gemountet sind, versuche ich, den Fehler mit e2fsck zu beheben.
Ursprünglich habe ich es verwendet, e2fsck -n /dev/mmcblk0pN (N is partition number)um nach Fehlern in der Dateisystempartition zu suchen.
Der obige Befehl lieferte jedoch ein falsches Ergebnis, wenn die Partition gemountet ist und Dateien auf der Partition erstellt werden.
Jetzt brauchte ich eine Alternative zum Überprüfen von Dateisystemfehlern.
Eine Möglichkeit besteht darin, tune2fs -leinen Befehl für das Feld „Partitionsprüfung“ zu verwenden Filesystem state.
Jetzt bin ich nicht sicher, ob dieses Feld zum Prüfen von Dateisystemfehlern zuverlässig ist oder nicht. Und welche möglichen Werte kann dieses Feld haben? Ich habe seine Werte gesehen clean, clean with errorsaber not cleanich bekomme keine weiteren Informationen von der Manpage.
Ist es also tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”zuverlässig, Dateisystemfehler zu erkennen? Gibt es eine bessere Möglichkeit, Dateisystemfehler in der Partition zu erkennen?
Irgendwelche Vorschläge/Hinweise/Informationen?
Antwort1
„Tune2fs -l“ zeigt Ihnen an, ob der Kernel während der Ausführung Dateisystembeschädigungen festgestellt hat. Wenn Sie beispielsweise ext4 auffordern, eine Datei zu löschen, und ext4 feststellt, dass einige der Blöcke in dieser Datei bereits als freigegeben markiert waren, bedeutet dies, dass die Zuordnungsbitmap beschädigt ist. Beachten Sie, dass die Zuordnungsbitmap bereits beschädigt war, als ext4 sie entdeckte. Tatsächlich könnte sie bereits seit Tagen oder Wochen beschädigt gewesen sein, und wenn Sie neue Dateien geschrieben hätten, könnte ext4 möglicherweise Blöcke für neue Dateien zugewiesen haben, die für ältere Dateien verwendet wurden, und der Benutzer könnte dadurch Daten verloren haben.
Die einzige Möglichkeit, zuverlässig festzustellen, ob ein Dateisystem konsistent ist oder beschädigt ist, besteht darin, e2fsck darauf auszuführen. Dazu muss das Dateisystem entweder ausgehängt oder ein schreibgeschützter Snapshot erstellt werden. (Wenn Sie LVM verwenden, können Sie einen schreibgeschützten Snapshot erstellen, diesen überprüfen und dann, wenn sich herausstellt, dass das Dateisystem beschädigt ist, entweder das System neu starten und e2fsck das Dateisystem reparieren lassen oder eine E-Mail an den Systemadministrator senden, um eine Ausfallzeit zur Reparatur des Dateisystems zu vereinbaren.)
Wenn das Dateisystem beschädigt ist, liegt das in den meisten Fällen wahrscheinlich an einem Hardwareproblem. Es ist möglich, dass es an einem Kernel-Fehler liegt, obwohl ich regelmäßig Regressionstests mit den stabilen Kerneln durchführe, nicht nur mit Upstream, und wir seit sehr langer Zeit kein Problem mit einer FS-Beschädigung mehr hatten. Es ist möglich, dass ein Speicherbeschädigungsfehler in einem Gerätetreiber vorliegt und entweder (a) der Gerätetreiber nicht Upstream ist und der Hardwareanbieter keine angemessene Qualitätskontrolle durchgeführt hat oder (b) der Fehler Upstream behoben und sogar auf den neuesten stabilen Kernel übertragen wurde, aber der Gerätekernel keine Updates aus der stabilen Kernel-Serie übernommen hat.
Beachten Sie, dass Sie nicht einfach dmesg oder /var/log/messages durchsuchen müssen, wenn Sie herausfinden möchten, ob das Dateisystem beschädigt ist, weil der Kernel über etwas offensichtlich Falsches gestolpert ist. Sie können auch versuchen, die Datei /sys/fs/ext4//first_error_time zu lesen. Wenn diese Datei einen Wert ungleich Null enthält, erfahren Sie, wann (unter Verwendung der Unix-Epoche) eine Beschädigung des Dateisystems vom Kernel erkannt wurde. Die Datei errors_count in diesem Verzeichnis gibt an, wie viele Beschädigungen des Dateisystems erkannt wurden (aber das kann auch einfach daran liegen, dass das System immer wieder über dasselbe Problem stolpert). Interessant ist auch, dass Sie, wenn Sie testen möchten, wie Ihr System mit vom Kernel erkannten Dateisystemfehlern umgeht, versuchen können, eine Zeichenfolge in die Datei trigger_fs_error zu schreiben – z. B. echo „test error“ > /sys/fs/ext4/sda1/trigger_fs_error“
Schauen Sie sich zum Schluss noch den Regler für das Fehlerverhalten an, den Sie in tune2fs einstellen können. Wenn Sie wirklich sicherstellen möchten, dass nach der Erkennung einer Dateisystembeschädigung kein weiterer Schaden entsteht, sollten Sie das Dateisystem so konfigurieren, dass es sich bei Erkennung eines Problems schreibgeschützt neu einbindet – oder vielleicht einfach einen Neustart erzwingen, damit e2fsck während der Startreihenfolge ausgeführt werden kann, um ein Problem zu beheben, bevor (noch mehr) Benutzerdaten beschädigt werden oder verloren gehen.