Zusätzlich zum regulären Protokollierungssystem hat BTRFS eine Statistik Befehl, der Fehler (einschließlich Lese-, Schreib- und Beschädigungs-/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
Sie könnten also einen einfachen Root-Cronjob erstellen:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Dadurch wird stündlich nach positiven Fehlerzahlen 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 fortgeschrittenen Dateisystemen wie BTRFS (mit Prüfsummen) oft empfohlen, alle paar Wochen eine Bereinigung zu planen, um stille Beschädigungen durch ein fehlerhaftes Laufwerk zu erkennen.
@monthly /sbin/btrfs scrub start -Bq /data
Der -B Option behält das Scrub im Vordergrund, sodass Sie die Ergebnisse in der E-Mail sehen, die Cron Ihnen sendet. Andernfalls läuft es im Hintergrund und Sie müssten daran denken, die Ergebnisse manuell zu überprüfen, da sie nicht in der E-Mail enthalten wären.
Aktualisieren :Verbessertes grep, wie von Michael Kjörling vorgeschlagen, danke.
Aktualisierung 2 :Zusätzliche Hinweise zum Scrubbing im Vergleich zu regulären Lesevorgängen (dies gilt nicht nur für BTRFS):
Wie Ioan betonte, 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, er erkennt keine zukünftigen Fehler - das Ziel eines Scrubs ist es, Fehler auf Ihren Laufwerken zu diesem Zeitpunkt zu finden und zu beheben. Aber wie bei anderen RAID-Systemen wird empfohlen, regelmäßige Bereinigungen zu planen. Es stimmt, dass eine typische I/O-Operation, wie das Lesen einer Datei, überprüft, ob die gelesenen Daten tatsächlich korrekt sind. Aber denken Sie an einen einfachen Spiegel - wenn die erste Kopie der Datei beschädigt ist, vielleicht durch ein Laufwerk, das kurz vor dem Tod steht, aber die zweite Kopie, die korrekt ist, tatsächlich von BTRFS gelesen wird, dann weiß BTRFS nicht, dass es eine Beschädigung gibt auf einem der Laufwerke. Dies liegt einfach daran, dass die angeforderten Daten empfangen wurden und mit der Prüfsumme übereinstimmen, die BTRFS für diese Datei gespeichert hat, sodass BTRFS die andere Kopie nicht lesen muss. Das bedeutet, dass selbst wenn Sie speziell eine Datei lesen, von der Sie wissen, dass sie auf einem Laufwerk beschädigt ist, es keine Garantie dafür gibt, dass die Beschädigung durch diesen Lesevorgang erkannt wird.
Nehmen wir nun an, BTRFS liest immer nur vom guten Laufwerk, es wird kein Scrub ausgeführt, der den Schaden auf dem schlechten Laufwerk erkennen würde, und dann geht auch das gute Laufwerk kaputt - die Folge wäre Datenverlust (zumindest würde BTRFS es wissen welche Dateien noch korrekt sind und Ihnen weiterhin erlauben, diese zu lesen). Dies ist natürlich ein vereinfachtes Beispiel; In Wirklichkeit liest BTRFS nicht immer von einem Laufwerk und ignoriert das andere.
Aber der Punkt ist, dass regelmäßige Scrubs wichtig sind, weil sie Fehler finden (und beheben), die normale Leseoperationen nicht unbedingt erkennen 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. sterbendes Laufwerk, das Fehler verursacht, aber noch zugänglich ist).
Wenn andererseits ein Laufwerk plötzlich ausfällt (getrennt oder vollständig tot, anstatt zu sterben und Fehler zu produzieren), wäre es ein fehlerhaftes Laufwerk (ZFS würde ein solches Laufwerk als FAULTED markieren). Leider erkennt BTRFS möglicherweise nicht, dass ein Laufwerk weg ist, während das Dateisystem gemountet ist, wie in diesem Mailinglisteneintrag von 09/2015 aufgezeigt wird (es ist möglich, dass dies gepatcht wurde):
Der Unterschied besteht darin, dass wir Code haben, um zu erkennen, dass ein Gerät beim Mounten nicht vorhanden ist, wir haben (noch) keinen Code, um zu erkennen, dass es auf einem gemounteten Dateisystem abgelegt wird. Warum die korrekte Erkennung eines verschwindenden Geräts keine Priorität zu haben scheint, habe ich keine Ahnung, aber das ist ein anderes Problem als das Mount-Verhalten.
https://www.mail-archive.com/[email protected]/msg46598.html
Zu diesem Zeitpunkt würde es in dmesg unzählige Fehlermeldungen geben, sodass das Grepping von dmesg möglicherweise nicht zuverlässig ist.
Für einen Server, der BTRFS verwendet, könnte es eine Idee sein, eine benutzerdefinierte Prüfung (Cron-Job) zu haben, die eine Warnung sendet, wenn mindestens eines der Laufwerke im RAID-Array weg ist, d. h. nicht mehr zugänglich ist ...
Ab btrfs-progs v4.11.1 hat Statistik die Option --check, die Nicht-Null zurückgibt, wenn einer der Werte nicht Null ist, wodurch die Notwendigkeit für die Regex entfällt.
Gerätestatistik -c /
Ich würde mich bei der Fehlermeldung nicht auf den Befehl stats verlassen, da dieser Befehl keinen Fehler zurückgibt, wenn ein Laufwerk plötzlich ausfällt. Sie können es testen, indem Sie ein SATA-Kabel trennen oder ein Laufwerk herausziehen - nicht empfohlen bei einem wichtigen Dateisystem.
btrfs device stats /
Nach einem Neustart zeigt btrfs fehlende Laufwerke an, aber das kann zu spät sein.
btrfs fi show