"Tune2fs -l" sagt Ihnen, ob der Kernel während seiner Ausführung auf Probleme mit dem Dateisystem aufmerksam geworden ist. Wenn Sie beispielsweise ext4 zum Löschen einer Datei auffordern und Ext4 feststellt, dass einige Blöcke in dieser Datei bereits als freigegeben markiert wurden, bedeutet dies, dass die Zuweisungsbitmap beschädigt ist. Beachten Sie, dass die Zuweisungsbitmap zum Zeitpunkt der Erkennung durch ext4 bereits beschädigt war. Tatsächlich könnte es seit Tagen oder Wochen beschädigt worden sein. Wenn Sie neue Dateien geschrieben haben, ist es möglich, dass ext4 Blöcke für neue Dateien zugewiesen hat, die für ältere Dateien verwendet wurden, und der Benutzer hat möglicherweise Daten verloren Ergebnis.
Die einzige Möglichkeit, zuverlässig zu sagen, ob ein Dateisystem konsistent ist oder nicht, ist die Ausführung von e2fsck. Dazu muss entweder das Dateisystem ausgehängt werden oder ein schreibgeschützter Snapshot erstellt werden. (Wenn Sie LVM verwenden, können Sie einen schreibgeschützten Snapshot erstellen, den schreibgeschützten Snapshot überprüfen. Wenn das Dateisystem beschädigt ist, können Sie entweder das System neu starten und das Dateisystem von e2fsck reparieren lassen. oder senden Sie eine E-Mail an den Systemadministrator, um Ausfallzeiten festzulegen, um das Dateisystem zu beheben.)
Alles in allem, wenn das Dateisystem beschädigt wurde, liegt dies wahrscheinlich an einem Hardwareproblem, das der häufigste Fall ist. Es ist möglich, dass es an einem Kernel-Fehler liegen könnte, obwohl ich regelmäßig Regressionstests auf den stabilen Kerneln durchführe, nicht nur beim Upstream, und wir haben seit langem kein Korruptionsproblem für fs gehabt. Es ist möglich, dass in einem Gerätetreiber ein Speicherbeschädigungsfehler aufgetreten ist und entweder (a) der Gerätetreiber nicht im Upstream-Modus ist und der Hardwarehersteller keine ordnungsgemäße Qualitätskontrolle durchgeführt hat oder (b) der Fehler im Upstream-Modus behoben wurde und sogar auf den neuesten stabilen Kernel getrieben, aber der Gerätekernel nahm keine Updates aus der stabilen Kernel-Serie.
Wenn Sie feststellen, ob das Dateisystem als fehlerhaft befunden wurde, weil der Kernel auf etwas offensichtlich Falsches gestoßen ist, müssen Sie nicht nur dmesg oder / var / log / messages scrape. Sie können auch versuchen, die Datei / sys / fs / ext4 // first_error_time zu lesen. Wenn diese Datei einen Wert ungleich Null enthält, wird Ihnen der Zeitpunkt (unter Verwendung der Unix-Epoche) mitgeteilt, zu dem eine Beschädigung des Dateisystems vom Kernel festgestellt wurde. Die Datei errors_count in diesem Verzeichnis sagt Ihnen, wie viele Dateisystembeschädigungen festgestellt wurden (dies kann jedoch nur der Fall sein, dass das System dasselbe Problem immer wieder auslöst). Wenn Sie testen möchten, wie Ihr System Dateisystemfehler behandelt, die vom Kernel erkannt werden, können Sie auch versuchen, einen String in die trigger_fs_error -Datei zu schreiben, z. B. Echo "test error">
Zum Schluss schauen Sie sich bitte den Fehlerverhalten-Knopf an, den Sie in tune2fs einstellen können. Wenn Sie wirklich sicherstellen möchten, dass nach dem Erkennen eines Dateisystemproblems kein größerer Schaden entsteht, können Sie das Dateisystem so konfigurieren, dass es sich selbst wieder schreibgeschützt meldet, wenn ein Problem gefunden wird. oder erzwingen Sie einfach einen Neustart, damit e2fsck während der Startsequenz ausgeführt werden kann, um ein Problem zu beheben, bevor (noch mehr) Benutzerdaten beschädigt werden oder verloren gehen.