Zusätzlich zum regulären Protokollierungssystem verfügt BTRFS über einen Statistikbefehl , der Fehler (einschließlich Lese-, Schreib- und Korruptions- / Prüfsummenfehler) pro Laufwerk verfolgt:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
So können Sie einen einfachen Root-Cronjob erstellen:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Dadurch wird stündlich nach positiven Fehlern gesucht und Ihnen eine E-Mail gesendet. Natürlich würden Sie ein solches Szenario testen (z. B. indem Sie eine Beschädigung verursachen oder das grep entfernen), um zu überprüfen, ob die E-Mail-Benachrichtigung funktioniert.
Darüber hinaus wird bei erweiterten Dateisystemen wie BTRFS (mit Prüfsummen) häufig empfohlen, alle paar Wochen ein Scrub zu planen, um eine stille Beschädigung durch ein fehlerhaftes Laufwerk zu erkennen.
@monthly /sbin/btrfs scrub start -Bq /data
Die -BOption hält das Peeling im Vordergrund, sodass Sie die Ergebnisse in der E-Mail sehen, die cron Ihnen sendet. Andernfalls wird es im Hintergrund ausgeführt und Sie müssen daran denken, die Ergebnisse manuell zu überprüfen, da sie nicht in der E-Mail enthalten sind.
Update : Verbessertes grep wie von Michael Kjörling vorgeschlagen, danke.
Update 2 : Zusätzliche Hinweise zum Scrubben im Vergleich zu regulären Lesevorgängen (dies gilt nicht nur für BTRFS):
Wie Ioan betont hat, kann ein Scrub je nach Größe und Typ des Arrays (und anderen Faktoren) viele Stunden dauern, in einigen Fällen sogar mehr als einen Tag. Und es ist ein aktiver Scan, der zukünftige Fehler nicht erkennt. Ziel eines Scrubs ist es, zu diesem Zeitpunkt Fehler auf Ihren Laufwerken zu finden und zu beheben. Wie bei anderen RAID-Systemen wird jedoch empfohlen, regelmäßige Scrubs zu planen. Es ist wahr, dass eine typische E / A-Operation wie das Lesen einer Datei prüft, ob die gelesenen Daten tatsächlich korrekt sind. Betrachten Sie jedoch einen einfachen Spiegel: Wenn die erste Kopie der Datei beschädigt ist, möglicherweise durch ein Laufwerk, das kurz vor dem Absterben steht, die zweite Kopie, die korrekt ist, tatsächlich von BTRFS gelesen wird, weiß BTRFS nicht, dass eine Beschädigung vorliegt auf einem der Laufwerke. Dies liegt einfach daran, dass die angeforderten Daten empfangen wurden.Dies bedeutet, dass selbst wenn Sie speziell eine Datei lesen, von der Sie wissen, dass sie auf einem Laufwerk beschädigt ist, keine Garantie dafür besteht, dass die Beschädigung durch diesen Lesevorgang erkannt wird.
Nehmen wir nun an, dass BTRFS immer nur vom guten Laufwerk liest, kein Scrub ausgeführt wird, das den Schaden auf dem fehlerhaften Laufwerk erkennt, und dann wird auch das gute Laufwerk fehlerhaft - das Ergebnis wäre ein Datenverlust (zumindest würde BTRFS dies wissen Welche Dateien sind noch korrekt und können noch gelesen werden? Dies ist natürlich ein vereinfachtes Beispiel. In der Realität liest BTRFS nicht immer von einem Laufwerk und ignoriert das andere.
Der Punkt ist jedoch, dass regelmäßige Scrubs wichtig sind, da sie Fehler finden (und beheben), die bei regulären Lesevorgängen nicht unbedingt erkannt werden.
Fehlerhafte Laufwerke : Da diese Frage sehr beliebt ist, möchte ich darauf hinweisen, dass diese "Überwachungslösung" dazu dient, Probleme mit möglicherweise fehlerhaften Laufwerken zu erkennen (z. B. aussterbende Laufwerke, die Fehler verursachen, aber immer noch zugänglich sind).
Wenn andererseits ein Laufwerk plötzlich ausfällt (getrennt oder vollständig tot, anstatt zu sterben und Fehler zu erzeugen), handelt es sich um ein fehlerhaftes Laufwerk (ZFS würde ein solches Laufwerk als FEHLERHAFT markieren). Leider kann BTRFS nicht erkennen, dass ein Laufwerk während des Bereitstellens des Dateisystems nicht mehr vorhanden ist, wie in diesem Mailinglisteneintrag vom 09.09.15 angegeben (möglicherweise wurde dies gepatcht):
Der Unterschied besteht darin, dass wir Code haben, um ein Gerät zu erkennen, das beim Mounten nicht vorhanden ist. Wir haben (noch) keinen Code, um zu erkennen, dass es auf einem gemounteten Dateisystem abgelegt wird. Ich habe keine Ahnung, warum die ordnungsgemäße Erkennung eines verschwundenen Geräts keine Priorität zu haben scheint. Ich habe keine Ahnung, aber das ist ein vom Mount-Verhalten getrenntes Problem.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
Zu diesem Zeitpunkt würde es in dmesg Unmengen von Fehlermeldungen geben, sodass das Greppen von dmesg möglicherweise nicht zuverlässig ist.
Für einen Server, der BTRFS verwendet, kann es sinnvoll sein, eine benutzerdefinierte Prüfung (Cron-Job) durchzuführen, die eine Warnung sendet, wenn mindestens eines der Laufwerke im RAID-Array nicht mehr verfügbar ist, dh nicht mehr verfügbar ist.