HDD regelmäßig auf Fehler prüfen

[s837ubc]

Hallo,

habe ein kleinen Debian Server im 24h Betrieb am Laufen.

Um rechtzeitig auf etwaige Fehler der HDD-Partition reagieren zu können suche ich ein geeignetes Verfahren.

SmartCtl ist mir schon bekannt und wird bereits eingesetzt. Meiner Kenntnissen nach prüft SmartCtl nur die Sektoren, nicht jedoch etwaige Partitionsfehler bzw. bei ext3/ext4 entstandene logische Fehler in der Dateistruktur.

e2fsck kann ja leider nur auf Partitionen eingesetzt werden, die nicht gemountet sind. Hierfür ein automatisches Verfahren zu entwickeln dürfte schwierig sein, da hierbei ja fast alle laufenden Prozesse beendet werden müssten. Nach dem Durchführen der Check-Vorgänge müssten die zuvor beendeten Prozesse wieder gestartet werden. Bei einem händischen Verfahren dieser Variante hat sich schnell herausgestellt, dass manche Pozesse direkt nach dem Beenden automatisch wieder von selbst gestartet worden sind, einige wenige haben sogar gar nicht auf ein Beenden-Signal reagiert.

Frage: Gibt es ein Verfahren oder ein geeignetes Programm, welches ähnlich wie e2fchk auch gemountete Partitionen auf Fehler prüfen kann?

[Six]

Nein, ein solches Programm gibt es nicht. Aktuellere FS, z. B. ZFS oder BtrFS bieten solche Funktionalität, ext4 aber nicht.

Was du tun kannst, ist regelmäßig

Code: Alles auswählen

fsck -n

durchführen und bei gefundenen Fehlern eine Warnung absetzen. Dann kannst du weitere Maßnahmen ergreifen.

[maltris]

@OP:

Hast du für smartctl bereits eine geeignete automatisierte Lösung?

Auf meiner Checklist ist noch immer das schreiben eines Skriptes, welches als Cronjob mehrfach ausgeführt werden kann und Änderungen der verschiedenen smartctl-Outputs anzeigt (bspw. reallozierte Sektoren) und dann eine Warnmeldung raussendet.

[Six]

smartd kann das alles. smartd wird in der Datei /etc/smartd.conf konfiguriert und lässt sich recht feinkörnig einstellen.

[s837ubc]

Hallo,

vielen Dank für die Informationen. Bei der vorhandenen Festplatte handelt es sich um eine SSD-Platte.

[Six]

OK, jetzt wo das alles gesagt ist, noch ein paar Sätze zum Disk Health Monitoring im allgemeinen:

1) Verlasst euch nicht auf SMART. SMART ist kein zuverlässiger Indikator für plötzlichen Disk-Tod. Nützlich sind aber folgende vier (bzw. für SSDs fünf) Werte trotzdem:

• scan errors
• reallocation count
• offline reallocation
• probational count
• und für SSDs: wear level count

Die erste vier Werte sind für HDDs besonder interessant, weil es Korrelationen zwischen diesen Fehlern und dem baldigen Ausfall der Platte gibt. Am aussagekräftigsten ist dabei der scan errors Wert. Nach dem ersten scan error steigt die statistische Ausfallwahrscheinlichkeit einer 1-Jahr alten HDD über das nächste Quartal von etwa 2% auf über 80%!

Im Gegensatz zu HDDs haben SSDs ein eingebauten EOL-Punkt -- irgendwann lassen sich die Zellen nicht mehr beschreiben. Das bedeutet, es ist sehr gut absehbar, wenn die SSD -- abgesehen von normalen Defekten -- ihrem Ende entgegen geht. Der Indikator dafür ist wear level count. Wichtig ist hier im wesentlichen, dass das ein inverser Indikator ist. 100 (wie in Prozent ) ist der Bestwert, von da geht es nur noch Berg ab. Erreicht der wear level count eine Wert <25, dann bereitet euch auf den baldigen Ausfall der SSD vor. Wie schnell das kommt hängt von der SSD ab, am besten guckt man sich die Anzahl der P/E-Cycles für seine SSD an und berechnet, wieviel Daten man am Tag durchschiebt und kann so einen Erwartungswert berechnen, wie schnell der wear level count fallen sollte. Gibt es hier Abweichungen, Augen auf!

2) Nehmt Statistik ernst! Normale Defekte machen mehr als die Hälfte der Ausfälle aus! SMART kann bei mechanischen Platten unter Umständen anschlagen, weil z. B. seek times hoch gehen oder halt Blöcke realloziert werden müssen. Aber elektronische Bauteile fallen auch aus und dass meistens von "OK" zu "FAIL" in einem Moment auf den anderen. Da kann kein Monitorsystem vorwarnen. Deswegen betreibt LCM für eure Platten und achtet auf die Statistiken von großen Speicheranbietern wie Google, Amazon oder der T-Kom. Selbst bei den besten Platten am Markt geht die AFR im dritten Jahr auf ca. 6%!

[s837ubc]

Hi Six,

vielen Dank für die ergänzenden Informationen.

Speziell "wear level count" ist mir unbekannt.

In Linux wird der Wert "177 wear level count" bei der Ausgabe des Befehls smartctl -a /dev/sda nicht ausgewiesen.

Da beim Cubietruck leider noch kein funktionierender Bootvorgang vom Nand-Speicher durchgeführt werden kann, muss das System weiterhin von einer SD Card erfolgen.

Beim Einsatz von diversen SD Cards (verschiedenste Typen und Hersteller) tritt im Laufe von einigen Tagen bis spätestens 2 Wochen immer wieder irgendwelche Dateisystemfehler auf.

Bislang habe ich mir damit beholgen, dass vor einem Reboot der Befehl touch /forchefsck ausgeführt wurde. Beim nachfolgenden Reboot werden dann meistens alle Fehler bereinigt.

Das Verfahren funktioniert natürlich nur, solange die betroffene Partition selbst noch nicht geladen ist.

Da von der SD Card gebootet wird, kann diese selbst nicht mehr von etwaigen Fehlern bereinigt werden.

Daraufhin wurde auf der SD Card eine zusätzliche Partition vor der bestehenden angelegt und mit boot markiert.

In die neue Bootpartition (mit ext3 formatiert) wurde der Inhalt des Ordners boot kopiert.

Dennoch wird scheinbar weiterhin von der zweiten Datenpartition gebootet.

Nach dem Booten wird weiterhin die zweiten Partition als erste Partition und die neue Bootpartition als zweite Partition im System registriert.

Kann mir jemand mitteilen, was man unternehmen muss, damit das System von der neuen Boot-Partition bootet?

In /etc/fstab stehen folgende Inhalte:

Code: Alles auswählen

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/mmcblk0p1  /           ext4    defaults,noatime,nodiratime,data=writeback,commit=600,errors=remount-ro        0       0