Wie sinnvoll ist ein regelmässiger Test mit mdadm/checkarray?

Probleme mit Samba, NFS, FTP und Co.
Antworten
Benutzeravatar
MSfree
Beiträge: 10657
Registriert: 25.09.2007 19:59:30

Wie sinnvoll ist ein regelmässiger Test mit mdadm/checkarray?

Beitrag von MSfree » 09.02.2021 12:30:19

Mein großes RAID5 (4 Platten, 40TiB netto) hat den ganzen letzten Sonntag vor sich hin gerattert. Als Ursaache hat sich herausgestellt, daß unter /etc/cron.d eine Datei namens mdadm existiert, die folgenden Inhalt hat:

Code: Alles auswählen

57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
Es wird also am zweiten Sonntag eines jeden Monats ein checkarray aufgerufen. Bei 4 14TB-Platten dauert das halt fast den ganzen Tag.

Ich sehe im Moment keinen Grund, warum man das tun sollte. Wenn eine Platte kaputt geht, wird das System das auch ohne checkarray erkennen.
Zuletzt geändert von MSfree am 10.02.2021 19:11:43, insgesamt 1-mal geändert.

Benutzeravatar
heisenberg
Beiträge: 3438
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von heisenberg » 09.02.2021 12:47:45

Platten können ja auch schleichend kaputt gehen. Gerade die Belastung durch eine Überprüfung, könnte eine Platte dazu bringen auszusteigen.

Falls das nicht stattfindet, kann es sein, dass dir im Fehlerfall vielleicht nicht nur 1 sondern 2(oder 3) aussteigen und damit sind deine Daten futsch(bzw. müssen langwierig vom Backup wiedereingespielt werden). Das Problem ist mit Sicherheit nicht jetzt, wo die Platten vielleicht noch recht neu sind, aber irgendwann, wenn die mal ein paar Jahre gelaufen sind, dann sieht's vielleicht anders aus. Gerade das ist die Geschichte, die ich bei RAID-5 häufig gelesen habe.

Über die Vergrößerung des Intervalls könnte man nachdenken.

Ich hatte schon diverse Situationen, wo mehrere Platten auf der Kippe standen. Manchmal funktioniert der Resync dann halt einfach nicht mehr, weil zusätzlich zur ausgefallenen Platte dann noch Lesefehler auf anderen Platten dazu kommen. (Bei HW-RAID-Controllern funktioniert das manchmal schon noch, aber wie stark intern der Zufallsgenerator dann bei nicht lesbaren Daten verwendet wird, dass weiss man da manchmal nicht).

Ich frage mich da grundsätzlich auch bzgl. der Datenintegrität. Schleichende Datenkorruption(Bit-Rot). erkennt ja MDADM nicht, oder? So wie ich z. B. das lese...

https://www.thomas-krenn.com/en/wiki/Md ... vs._Repair

repariert MDADM nur bei Lesefehlern. Das bedeutet ja, dass da (erwartungsgemäss) keine Checksummen im Spiel sind, die verifizieren ob der Inhalt auf der Platte tatsächlich noch korrekt ist. (Aber über das verwendete Dateisystem hast Du ja noch nichts geschrieben.)
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
MSfree
Beiträge: 10657
Registriert: 25.09.2007 19:59:30

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von MSfree » 09.02.2021 13:53:08

heisenberg hat geschrieben: ↑ zum Beitrag ↑
09.02.2021 12:47:45
Über die Vergrößerung des Intervalls könnte man nachdenken.
Ich denke, ich werde es vor allem mal auf einen anderen Wochentag legen. Sonntags muß die Kiste nicht unbedingt mit den Leseköpfen klappern, wochentags stört mich das weniger, da bin ich nicht zuhause.
Ich frage mich da grundsätzlich auch bzgl. der Datenintegrität. Schleichende Datenkorruption(Bit-Rot). erkennt ja MDADM nicht, oder? So wie ich z. B. das lese...
Das RAID dient als Backup für meinen Heimserver, falls dem mal die Platte abraucht. Dann kann ich den Bestand relativ schnell wieder herstellen. Sollten Serverplatte und 2 Platten des RAIDs gleichzeitig abrauchen, hätte ich immer noch ein weiteres Backup, da dauert es aber länger, bis ich da ankomme. Ich denk, die Datensicherheit ist nicht das ganz große Problem. :wink:

Prüfsummen halte ich in meinem Fall für entbehrlich. Die können einem ja nur sagen, daß eine Datei kaputt ist. Den Defekt reparieren können sie nicht. Natürlich ist es bei einem Produktivserver sinnvoll, rechtzeitig zu erfahren, daß eine Datei defekt ist, um sie dann vom Backup restaurieren zu können. Wenn aber das Backup defekt ist, kann man nur versuchen, in noch älteren Backups zu suchen.

Und da ich ein Freund von KISS bin, habe ich da auch "nur" ein ext4 auf dem RAID. Im Grunde ist aber RAID5 schon gegen Bitrots halbwegs resistent. Denn dann schlägt ja die Redundanzinformation zu und korrrigiert den Datenfehler (hoffentlich mit entsprechender Logmeldung).

Benutzeravatar
heisenberg
Beiträge: 3438
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von heisenberg » 09.02.2021 14:13:41

MSfree hat geschrieben: ↑ zum Beitrag ↑
09.02.2021 13:53:08
Prüfsummen halte ich in meinem Fall für entbehrlich. Die können einem ja nur sagen, daß eine Datei kaputt ist. Den Defekt reparieren können sie nicht.
Ich meinte die im Dateisystem integrierten Prüfsummen. ZFS / btrfs können die dann ja in einem RAID mit den redundaten Daten (automatisch) reparieren.
Im Grunde ist aber RAID5 schon gegen Bitrots halbwegs resistent. Denn dann schlägt ja die Redundanzinformation zu und korrrigiert den Datenfehler
Hier weiss ich halt nicht wie RAID-5 arbeitet. Wie stellt es fest, wo der fehlerhafte Datenblock ist? (Ist es der Parity-Block oder einer der Datenblöcke und wenn ja, welcher?) Das würde ja irgend eine Art interner Prüfsummen voraussetzen, mit denen Datenblöcke entweder als korrekt oder nicht bewertet werden kann. Oder liege ich hier falsch?
Zuletzt geändert von heisenberg am 09.02.2021 14:50:02, insgesamt 1-mal geändert.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
MSfree
Beiträge: 10657
Registriert: 25.09.2007 19:59:30

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von MSfree » 09.02.2021 14:30:52

heisenberg hat geschrieben: ↑ zum Beitrag ↑
09.02.2021 14:13:41
Ich meinte die im Dateisystem integrierten Prüfsummen. ZFS / btrfs können die dann ja in einem RAID mit den redundaten Daten (automatisch) reparieren.
ZFS ziehe ich für mich sowieso nicht in Betracht, das Lizenzgewackel ist mir zu unsicher, das Vertrauen haben die Entwickler leider verspielt. BTRFS hat so viele komische Eingenheiten, die ich entweder nicht verstehe oder dessen teilweise abstrusen Argumentationsketten der Entwickler in entsprechenden Foren ich nicht nachvollziehen kann, daß ich das FS eigentlich für mich abgeschrieben habe. Also werden ich ohne Prüfsummen auskommen müssen, oder es kommt irgendwann ein ext5.
Wie stellt es fest wo der fehlerhafte Datenblock ist?
Guter Punkt, ich weiß es aber auch nicht.

Benutzeravatar
heisenberg
Beiträge: 3438
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von heisenberg » 10.02.2021 01:26:58

MD RAID-5 kann keine schleichende Datenkorruption korrigieren, nur gemeldete Fehler(Lesefehler der Platte/Kompletter Plattenausfall) [1]. Es ansonsten kann nur feststellen ob Daten korrupt sind oder nicht und im Zweifelsfall die Parity neu berechnen. (Ob es das auch tatsächlich tut, wird mir aus dem Text im Kernel-Wiki nicht klar.)

RAID-6 kann einen defekten Datenblock schon auch der entsprechenden Platte zuordnen[1] aber es gibt trotzdem keine Option zur Reparatur. raid6check [2] kann anzeigen auf welcher Platte defekte Stripes liegen, aber korrigieren tut es das nicht. (Ist wohl zu kompliziert, obwohl es in der Theorie [3] geht).

[1] https://raid.wiki.kernel.org/index.php/ ... the_drives
[2] https://man7.org/linux/man-pages/man8/raid6check.8.html
[3] https://mirrors.edge.kernel.org/pub/lin ... /raid6.pdf
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
MSfree
Beiträge: 10657
Registriert: 25.09.2007 19:59:30

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von MSfree » 10.02.2021 08:19:47

heisenberg hat geschrieben: ↑ zum Beitrag ↑
10.02.2021 01:26:58
MD RAID-5 kann keine schleichende Datenkorruption korrigieren
Das hatte ich auch befürchtet. Daher ist dann eigentlich auch checkarray überflüssig. Habe ich schleichende Datenkorruption, kann checkarray sie sowieso nicht korrigieren, und ansonsten ist es einfach nur nervend, wenn das System den ganzen Tag vor sich hin rappelt.

Benutzeravatar
schorsch_76
Beiträge: 2532
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von schorsch_76 » 10.02.2021 09:24:28

Ich hatte letztens einen Ausfall eines Raid5. Ich habe den Checkarray Lauf jetzt auf 1 Woche gesetzt. Lieber rattert das Raid einmal in der Woche und ich erkenne einen Fehler frühzeitig als dass ich nochmal so ein Drama habe. Die relativ große Belastung sorgt auch dafür, dass ich mich auf das Ding halbwegs verlassen kann und es mir nicht um die Ohren fliegt weil irgendwas altert. Wenn es einen kompletten Scrub aushält, ist es wahrscheinlich brauchbar. Wenn es beim Scrub ausfällt und meckert, ist die Platte noch nicht so platt wie meine Platte letztens ;)

Bei Raid5 kann das System einen Fehler durchaus reparieren wenn es feststellen kann wo der Fehler ist und nur eine der Platten einen Schaden hat.
Wikepedia hat geschrieben: Bei RAID 5 ist die Datenintegrität des Arrays beim Ausfall von maximal einer Platte gewährleistet. Nach Ausfall einer Festplatte oder während des Rebuilds auf die Hotspare-Platte (bzw. nach Austausch der defekten Festplatte) lässt die Leistung deutlich nach (beim Lesen: jeder (n−1)-te Datenblock muss rekonstruiert werden; beim Schreiben: jeder (n−1)-te Datenblock kann nur durch Lesen der entsprechenden Bereiche aller korrespondierenden Datenblöcke und anschließendes Schreiben der Parität geschrieben werden; hinzu kommen die Zugriffe des Rebuilds: (n−1) × Lesen; 1 × Schreiben). Bei dem Rebuild-Verfahren ist daher die Berechnung der Parität zeitlich zu vernachlässigen; im Vergleich zu RAID 1 dauert somit das Verfahren unwesentlich länger und benötigt gemessen am Nutzdatenvolumen nur den (n−1)-ten Teil der Schreibzugriffe.
https://de.wikipedia.org/wiki/RAID#RAID ... nformation
Kernel Wiki hat geschrieben: echo check > /sys/block/mdX/md/sync_action

This causes the system to read the entire array looking for read errors. If a read error is encountered, the block in error is calculated and written back. If the array is a mirror, as it can't calculate the correct data, it will take the data from the first (available) drive and write it back to the dodgy drive. Drives are designed to handle this - if necessary the disk sector will be re-allocated and moved. SMART should be used to track how many sectors have been moved, as this can be a sign of a failing disk that will need replacing.

echo repair > /sys/block/mdX/md/sync_action

With a raid-5 array the only thing that can be done when there is an error is to correct the parity. This is also the most likely error - the scenario where the data has been flushed and the parity not updated is the expected cause of problems like this.
Das ist doch auch das was ich haben will.

Benutzeravatar
heisenberg
Beiträge: 3438
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Wie sinnvoll ist ein regelässiger Test mit mdadm/checkarray?

Beitrag von heisenberg » 10.02.2021 10:46:54

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.02.2021 08:19:47
heisenberg hat geschrieben: ↑ zum Beitrag ↑
10.02.2021 01:26:58
MD RAID-5 kann keine schleichende Datenkorruption korrigieren
Das hatte ich auch befürchtet. Daher ist dann eigentlich auch checkarray überflüssig.
Ich halte das checkarray für sehr sinnvoll, aus den bisher geschriebenen Gründen.

Wie schorsch auch schreibt bzw. zitiert: die Scrubs triggern evtl. SMART-Fehler(weil eben wirklich die ganze Platte getestet wird) und wenn die gehäuft auftreten, dann wäre es im Falle eines FS ohne Prüfsummen(ext4) Zeit die Platte zu wechseln.

Außerdem sorgt der Scrub dafür, dass überall dort, wo Lesefehler auftreten, diese korrigiert werden können. D. h. die Platte lagert den Sektor intern um(Smart: reallocated Sector) und schreibt den mit Hilfe des Parity-Blocks restaurierten Datenblock sauber neu. Meiner Erfahrung nach treten Lesefehler immer mal wieder auf. Am Ende der Lebenszeit geht die Anzahl etwas hoch kurz vor dem Totalausfall.

Hast Du einen Plattenausfall und treten dabei Lesefehler auf den guten Platten auf, dann hast Du für jeden solcher Lesefehler auch einen Datenfehler, der nicht behoben werden kann(Weil ausgefallene Platte + zusätzlicher Lesefehler insgesamt zwei Fehler sind und RAID-5 kann nur einen Fehler pro Stripe abfangen.) Das weitaus nervigere wäre aber eher, wenn ein RAID-5 im degraded Status keinen Rebuild mehr durchführen kann, weil es eben auf Datenfehler trifft. Einen Rebuild, den man vielleicht nach vorsorglichem Plattentausch angestossen hat.

Nachtrag

Es wäre also sehr sinnvoll, vor einem Plattentausch einen oder mehrere Scrub-Läufe durchzuführen, um die automatische Behebung aller nicht erkannten Datenfehler anzustossen. Wenn eine oder gar mehrere Platten ohnehin schon Schwächen zeigen, dann wäre das allerdings u. U. der Todesstoß für das RAID-Array. In diesem Fall wäre es dann wohl geschickter, das RAID gleich zu löschen, die Platten zu testen, und ggf. mit getesteten / einwandfrei funktionsfähigen Platten das RAID neu zu erstellen und aus dem Backup wiederherzustellen. Alternativ würde ich von einem RAID5, bei dem mehrere Platten Symptome von möglichem baldigem Ausfall zeigen, wenn es notwendig ist, die Daten davon zu behalten, einen zusätzlichen Datenspeicher anschließen um die Daten dorthin zu kopieren(evtl. mit Kopierfehlern; Wird bei 40 TB natürlich spannend).

Nachtrag 2
schorsch_76 hat geschrieben:Bei Raid5 kann das System einen Fehler durchaus reparieren wenn es feststellen kann wo der Fehler ist und nur eine der Platten einen Schaden hat.
Ja. Ganz genau: Wenn es feststellen kann, wo der Fehler ist. Bei schleichender Datenkorruption ist das halt nicht der Fall. Ich habe auch gelesen, dass Festplatten seit vielen Jahren(~1990) einfache Bitfehler selbst abfangen und korrigieren können. Nur mehrfache Bitfehler werden entweder als Lesefehler ohne korrigierte Daten zurückgeliefert(gut, weil das RAID sie dann rekonstruieren kann) oder als korrekte Daten(schlecht, weil der Fehler dann unerkannt bleibt und vom RAID nicht erkannt und behoben wird).

Hier eine Meinung von jemandem dazu, dass das eigentlich vollkommen ausreicht:

https://www.jodybruchon.com/2017/03/07/ ... nd-raid-5/
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Antworten