Ich habe ein Setup mit btrfs, das auf mdadm raid6 läuft, da der RAID5/6-Code von btrfs noch nicht stabil ist. Ich dachte, auf diese Weise würde ich die Vorteile von Snapshotting und Prüfsummenberechnungen mit ein paar zusätzlichen Hürden nutzen, aber jetzt, wo ich diese Hürden tatsächlich nehmen muss, stoße ich auf einige Probleme.
Heute Morgen hat mein dmesg dieses Problem verursacht:
BTRFS error (device md2): bad tree block start, want 28789209759744 have 7611175298055105740
BTRFS info (device md2): read error corrected: ino 0 off 28789209759744 (dev /dev/md2 sector 55198191488)
BTRFS info (device md2): read error corrected: ino 0 off 28789209763840 (dev /dev/md2 sector 55198191496)
BTRFS info (device md2): read error corrected: ino 0 off 28789209767936 (dev /dev/md2 sector 55198191504)
BTRFS info (device md2): read error corrected: ino 0 off 28789209772032 (dev /dev/md2 sector 55198191512)
Dies ist die Art von Sache, die unbemerkt hätte passieren können, wenn ich btrfs nicht verwendet hätte. Zumindest hat es mir also etwas genützt. Jetzt sollte ich also in der Lage sein, herauszufinden, welche Festplatte das Problem hat, und sie zu ersetzen, oder?
Nun, mdadm scheint nur die Ermittlung der fehlerhaften Festplatte mit dem Tool raid6check zu unterstützen. Ich musste es aus dem Quellcode erstellen, damit es unter Debian funktionierte, aber nachdem ich das getan hatte, schien es, als wäre ich im Geschäft.
Der einzige Haken dabei ist, dass dieses Tool extrem langsam zu sein scheint. Um 1000 Streifen zu scannen, braucht es gute 3 Minuten. Das bedeutet, dass es über 31 Tage dauern würde, um die 15261512 Streifen zu scannen, aus denen mein Array besteht. Das würde ich nach Möglichkeit vermeiden wollen. Die mdadm-Prüfung/-Reparatur ist viel schneller, nur etwa 3 Tage, liefert aber keine nützlichen Informationen darüber, welche Festplatte dafür verantwortlich sein könnte, also möchte ich sie nicht unbedingt verwenden.
Das Tool raid6check scheint die Annahme einer Streifennummer zu unterstützen. Ich frage mich, ob es möglich ist, zu berechnen, welche Streifennummer übergeben werden soll, damit ich den entsprechenden Teil der Festplatte direkt prüfen kann.
Hier sind die raid6check-Informationen zu Referenzzwecken, falls sie hilfreich sind:
layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288
Danke, alle Ideen sind willkommen.
Antwort1
Okay, ich habe eine einigermaßen funktionierende Möglichkeit gefunden, dies zu tun, nachdem ich mit JyZyXEL über #linux-raid auf Freenode gesprochen habe.
raid6check meldet die Gesamtzahl der Streifen. Führen Sie es daher wie folgt aus, um die grundlegenden Informationen anzuzeigen, ohne einen vollständigen Test auszuführen:
./raid6check /dev/md0 0 1
Sie erhalten ungefähr Folgendes:
layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288
Überprüfen Sie die Gesamtzahl der Sektoren in Ihrem RAID mit fdisk -l /dev/md0:
Disk /dev/md2: 43.7 TiB, 48008565620736 bytes, 93766729728 sectors
Berechnen Sie nun die Sektoren pro Streifen:
total sectors / total stripes = 93766729728 / 15261512 = 6144
Teilen Sie nun einfach den Sektor mit dem Fehler durch die Sektoren pro Streifen:
error sector = 55198191488/6144 = 8984080
Führen Sie jetzt einen raid6check aus und versuchen Sie, den umgebenden Bereich einzubeziehen, da dies nicht exakt zu sein scheint:
raid6check /dev/md0 8984000 1000
Bei mir führte dies schnell zu vielen relevanten Fehlern, die alle auf dieselbe Festplatte verwiesen, die möglicherweise defekt war:
Error detected at stripe 8984078, page 100: possible failed disk slot 1: 4 --> /dev/sdj1
Error detected at stripe 8984081, page 76: possible failed disk slot 4: 4 --> /dev/sdj1
Ab diesem Punkt können Sie entsprechend handeln, die Festplatte ersetzen, SMART-Tests ausführen, die automatische Reparatur von raid6check verwenden usw.
Dies ist vielleicht nicht die präziseste Methode, aber ich veröffentliche sie nur für den Fall, dass niemand sonst eine bessere Idee hat und jemand in Zukunft nach einer Methode sucht, die funktioniert.