Ich habe eine Dokumentation zu einem Daemon gesehen, der ein Programm/Skript für verschiedene BTRFS-Ereignisse ausführen kann, kann sie aber nicht mehr finden.
Wie kann ich bei einem Laufwerksfehler für ein BTRFS-RAID1-Array ein Skript/Programm ausführen lassen? Ich möchte bei jedem Fehler ein Skript ausführen, das als Frühwarnung für ein potenziell ausgefallenes Laufwerk dient, aber der eigentliche Laufwerksfehler ist am wichtigsten. Ich möchte das Dateisystem an diesem Punkt aushängen (falls BTRFS das nicht sowieso macht) und einen Alarm einstellen.
Antwort1
Zusätzlich zum regulären Protokollierungssystem verfügt BTRFS über einStatistikenBefehl, der Fehler (einschließlich Lese-, Schreib- und Beschädigungs-/Prüfsummenfehler) pro Laufwerk protokolliert:
# 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 wird eine E-Mail gesendet. Natürlich würden Sie ein solches Szenario testen (beispielsweise 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üfsummenfunktion) oft empfohlen, alle paar Wochen einen Scrub einzuplanen, um stille Beschädigungen durch ein fehlerhaftes Laufwerk zu erkennen.
@monthly /sbin/btrfs scrub start -Bq /data
Mit dieser -BOption bleibt der Scrub im Vordergrund, sodass Sie die Ergebnisse in der E-Mail sehen, die Cron Ihnen sendet. Andernfalls läuft er im Hintergrund und Sie müssen 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 von Ioan angemerkt, kann ein Scrubbing je nach Größe und Typ des Arrays (und anderen Faktoren) viele Stunden dauern, in manchen Fällen sogar mehr als einen Tag. Und da es sich um einen aktiven Scan handelt, werden zukünftige Fehler nicht erkannt – das Ziel eines Scrubbings besteht darin, Fehler auf Ihren Laufwerken zu diesem Zeitpunkt zu finden und zu beheben. Aber wie bei anderen RAID-Systemen wird empfohlen, regelmäßige Scrubbings einzuplanen. Es stimmt, dass ein typischer E/A-Vorgang, wie das Lesen einer Datei, prüft, ob die gelesenen Daten tatsächlich korrekt sind. Aber denken Sie an eine einfache Spiegelung – wenn die erste Kopie der Datei beschädigt ist, vielleicht durch ein Laufwerk, das kurz vor dem Absturz steht, aber die zweite Kopie, die korrekt ist, tatsächlich von BTRFS gelesen wird, dann weiß BTRFS nicht, dass auf einem der Laufwerke eine Beschädigung vorliegt. 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.Dies bedeutet, dass selbst wenn Sie gezielt 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 von dem intakten Laufwerk liest, kein Scrub ausgeführt wird, der den Schaden auf dem fehlerhaften Laufwerk erkennt, und dass dann auch das intakte Laufwerk fehlerhaft wird – das Ergebnis wäre ein Datenverlust (zumindest wüsste BTRFS, welche Dateien noch korrekt sind, und ließe Sie diese weiterhin lesen). Natürlich ist dies 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 bei normalen Lesevorgängen nicht unbedingt erkannt werden.
Fehlerhafte Laufwerke: Da diese Frage recht häufig gestellt wird, möchte ich darauf hinweisen, dass diese „Überwachungslösung“ dazu dient, Probleme mit möglicherweise fehlerhaften Laufwerken zu erkennen (z. B. ein sterbendes Laufwerk, das Fehler verursacht, aber immer noch zugänglich ist).
Wenn ein Laufwerk hingegen plötzlich nicht mehr vorhanden ist (getrennt oder komplett 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 erkennt BTRFS möglicherweise nicht, dass ein Laufwerk nicht mehr vorhanden ist, während das Dateisystem gemountet ist, wie in diesem Mailinglisteneintrag von 09/2015 erwähnt wird (möglicherweise wurde dies gepatcht):
Der Unterschied besteht darin, dass wir Code haben, um zu erkennen, dass ein Gerät beim Mounten nicht vorhanden ist, aber (noch) keinen Code, um zu erkennen, dass es auf einem gemounteten Dateisystem abgelegt wird. Warum die ordnungsgemäße Erkennung des Verschwindens eines Geräts keine Priorität zu haben scheint, weiß ich nicht, aber das ist ein anderes Problem als das Mount-Verhalten.
https://www.mail-archive.com/[email geschützt]/msg46598.html
Zu diesem Zeitpunkt würden in dmesg Unmengen von Fehlermeldungen erscheinen, sodass das Greppen von dmesg möglicherweise nicht zuverlässig ist.
Für einen Server, der BTRFS verwendet, wäre es möglicherweise eine gute Idee, eine benutzerdefinierte Prüfung (Cron-Job) durchzuführen, die eine Warnung sendet, wenn mindestens eines der Laufwerke im RAID-Array nicht mehr vorhanden ist, d. h. nicht mehr zugänglich ist ...
Antwort2
Ab btrfs-progs v4.11.1 verfügt stats über die Option --check, die einen Wert ungleich Null zurückgibt, wenn einer der Werte ungleich Null ist. Dadurch wird der reguläre Ausdruck nicht mehr benötigt.
device stats -c /
Antwort3
Ich würde mich bei der Fehlerbenachrichtigung nicht auf den Befehl stats verlassen, da dieser Befehl keinen Fehler zurückgibt, wenn ein Laufwerk plötzlich nicht mehr funktioniert. Sie können es testen, indem Sie ein SATA-Kabel trennen oder ein Laufwerk herausziehen – bei einem wichtigen Dateisystem nicht empfohlen.
btrfs device stats /
Nach einem Neustart zeigt btrfs fehlende Laufwerke an, aber das kann zu spät sein.
btrfs fi show
Antwort4
Klingt nach einer Aufgabe für die Systemüberwachung. Es gibt eine Prüfung, die die Nagios-Plugin-API implementiert und heißt:check_btrfs. Wie Sie im Quellcode sehen können, gibt es eine Funktion, check_dev_statsdie die Gerätestatistiken überprüft und kritisch wird, wenn einer der Werte ungleich Null ist. Sie prüft auch auf Zuordnungsprobleme. Was unklar bleibt, istwie sich die Prüfung verhält, wenn eine Festplatte fehlt oder offline geht.
PS: Das Plugin ist in Debian verpackt:Überwachungs-Plugins-btrfs