mabox schriebHi GerBra,
also nun hat nach dem Balance auch das booten von der anderen Platte geklappt. Es hagelte jede Menge BTRFS Fehler aber es bootete. Danach war das Filesystem aber nur read only. Nach einem erneuten Boot läuft hat aber alles wunderbar geklappt. Ich lass dann heute Nacht gleich wieder einen Balance laufen.
Na, dann hast du ja jetzt eine Zeitangabe, wie lange (Full-)Balance für dein Setup braucht ;-)
Nochmal Obacht: Balance ist eigentlich nur notwendig, wenn es wirklich was zu Blancieren gibt, es ist nicht das Standard-"Reperatur-"/Wartungs-Werkzeug für btrfs. S.u.
mabox schrieb
EDIT: Ok zu früh gefreut. Auch nach dem Reboot bleibt eine der beiden Platten read only.
EDIT: Ok, Ui Ui Ui, nach einem erneuten Reboot passt jetzt doch wieder alles.
Zum 1.Edit: "Eine der beiden Platten read only" verstehe ich nicht, meinst du das ganze Raid? Sollte nicht sein...
Zum 2.Edit: "Reboot tut immer gut" - alter Windowslehrsatz....
Nochmal zum Punkt Test und Balance. Ich teste immer noch im obigen Virtualbox-Setup (2xSSD, 2xHDD, 2 btrfs-Volumes).
Ich ziehe für vol_tank vorm boot die hdd1 ab, mounte per Hand vol_tank nach /mnt/tank, und kopiere ein paar Daten hinzu:
# btrfs file file show
Label: 'vol_root' uuid: 3a3f5672-8035-4771-a326-2c53538d3142
Total devices 2 FS bytes used 1.28GiB
devid 1 size 8.00GiB used 2.28GiB path /dev/sda1
devid 2 size 8.00GiB used 2.28GiB path /dev/sdb1
Label: 'vol_tank' uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
Total devices 2 FS bytes used 242.79MiB
devid 2 size 8.00GiB used 2.38GiB path /dev/sdc1
*** Some devices missing
(Also bei vol_tank fehlt devid 1, somit ist es faktisch kein Raid1 (mehr))
# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 2
Device size: 8.00GiB
Device slack: 3.50KiB
Data,single: 832.00MiB
Data,RAID1: 1.00GiB
Metadata,single: 256.00MiB
Metadata,RAID1: 256.00MiB
System,single: 32.00MiB
System,RAID1: 32.00MiB
Unallocated: 5.62GiB
missing, ID: 1
Device size: 0.00B
Device slack: 0.00B
Data,RAID1: 1.00GiB
Metadata,RAID1: 256.00MiB
System,RAID1: 32.00MiB
Unallocated: 6.72GiB
(Hier sieht man deutlich: Das btrfs agiert als Single-Device (für Daten wo überall single hinter Data,Metadata,System steht).
# btrfs dev stats /mnt/tank
[devid:1].write_io_errs 0
[devid:1].read_io_errs 0
[devid:1].flush_io_errs 0
[devid:1].corruption_errs 1041
[devid:1].generation_errs 2
[/dev/sdc1].write_io_errs 0
[/dev/sdc1].read_io_errs 0
[/dev/sdc1].flush_io_errs 0
[/dev/sdc1].corruption_errs 0
[/dev/sdc1].generation_errs 0
( Für das entfernte Device 1 hätten sich in der Fehlerstatistik nun bereits etliche Fehler(chunks) ergeben.)
Ich fahre das System runter, hänge die hdd1 wieder an ihren Platz. Das System bootet und mountet vol_tank -> /mnt/tank automatisch. Der Status nun ist:
# btrfs file file show
Label: 'vol_tank' uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
Total devices 2 FS bytes used 242.79MiB
devid 1 size 8.00GiB used 1.28GiB path /dev/sdc1
devid 2 size 8.00GiB used 2.38GiB path /dev/sdd1
(Hier nun der erste Hinweis: used bei beiden Devices ist nicht (mehr) gleich was bei raid1 eigentlich sein muß.)
# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 1
Device size: 8.00GiB
Device slack: 3.50KiB
Data,RAID1: 1.00GiB
Metadata,RAID1: 256.00MiB
System,RAID1: 32.00MiB
Unallocated: 6.72GiB
/dev/sdd1, ID: 2
Device size: 8.00GiB
Device slack: 3.50KiB
Data,single: 832.00MiB
Data,RAID1: 1.00GiB
Metadata,single: 256.00MiB
Metadata,RAID1: 256.00MiB
System,single: 32.00MiB
System,RAID1: 32.00MiB
Unallocated: 5.62GiB
(Hier ebefalls der definitive Hinweis, das Balance notwendig ist: sdd1, ID2 hat/hält die Daten, die eigentlich dem momentan gemouteten Datenbestand entsprechen - aber halt im Single-Mode, d.h. asynchron zum Raid1 mit sdc1, ID1 (die ja "weg" war))
Das ist also für mich der Gradmesser wo ein Balance-Lauf AFAIK zwingend notwendig ist um diese Single- vs. Raid1 Inkonsistenz aufzulösen. Das passiert nicht automatisch.
Also lasse ich ein: btrfs balance start --full-balance /mnt/tank los. Danach sehen die Werte dann so aus:
# btrfs file file show
Label: 'vol_tank' uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
Total devices 2 FS bytes used 242.55MiB
devid 1 size 8.00GiB used 1.28GiB path /dev/sdc1
devid 2 size 8.00GiB used 1.28GiB path /dev/sdd1
(Also used-Werte wieder identisch, gespiegelt)
# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 1
Device size: 8.00GiB
Device slack: 3.50KiB
Data,RAID1: 1.00GiB
Metadata,RAID1: 256.00MiB
System,RAID1: 32.00MiB
Unallocated: 6.72GiB
/dev/sdd1, ID: 2
Device size: 8.00GiB
Device slack: 3.50KiB
Data,RAID1: 1.00GiB
Metadata,RAID1: 256.00MiB
System,RAID1: 32.00MiB
Unallocated: 6.72GiB
("Single" Daten sind weg, Raid1 ist wieder synchron)
Sicherheitshalber lasse ich nochmal über das Dateisystem ein scrub laufen. Vorher lösche ich noch die Fehlerstatistik für vol_tank, da ich nach dem Balance eigentlich keine (neuen) Fehler mehr erwarte:
# btrfs dev stats -z /mnt/tank
[/dev/sdc1].write_io_errs 0
[/dev/sdc1].read_io_errs 0
[/dev/sdc1].flush_io_errs 0
[/dev/sdc1].corruption_errs 1041
[/dev/sdc1].generation_errs 2
[/dev/sdd1].write_io_errs 0
[/dev/sdd1].read_io_errs 0
[/dev/sdd1].flush_io_errs 0
[/dev/sdd1].corruption_errs 0
[/dev/sdd1].generation_errs 0
Der scrub-Lauf endet ohne weitere Fehler, die Statistik bleibt auf 0.
Das wäre jetzt der Punkt, an dem ich meinem Raid1 "wieder trauen" würde.
Also:
a) Balance als Reperatur-Werkzeug nur, wenn es auch was zu balancieren gibt.
b) Scrub reicht ansonsten aus, um ein intaktes btrfs-Raid1 zu prüfen und zu reparieren. Hier werden v.a. die Checksummen geprüft und - da greift dann der Vorteil von raid1 - eventuelle "korrupte" Daten anhand der korrekten Version vom jeweils anderen Device wieder synchronisiert (wenn möglich). Nach deinem erfolgreichen 1.Balance-Lauf hätte also ein Scrubbing vollkommen ausgereicht.
Scrub sollte man sowieso periodisch laufen lassen, das btrfs-Wiki empfiehlt einmal im Monat. Bei mir lasse ich es alle 2 Wochen laufen, da meine beiden HDs auch schon "überfällig" für Ausfälle sind. (Wiki auf archlinux.org für btrfs zeigt wie das mit systemd geht, mir persönlich sind cronjobs vertrauter)
Scrub hält also Dateisystem (und "Raid") in Ordnung, und zeigt auch aufgetretene Hardware-Probleme an
c) Die Fehlerstatistik sollte man auch periodisch prüfen, ich teste per cronjob alle Stunde ob Fehlerwerte auftreten:
/usr/bin/btrfs device stats /mnt/tank | grep -vE ' 0$'
Das grep sorgt dafür, daß nur Zeilen mit Wert ungleich 0 als Ergebniss kämen, über dieses evtuelle Ergebniss würde ich dann informiert.
Nach jeder "Reparatur" aufgrund von Fehlern sollte die Statistik logischerweise wieder zurückgesetzt werden.
d) Für ein Raid1 im "Heimbereich" bietet sich ein periodischer Smart-Test der beteiligten Platten ebenfalls an. (pacman -Si smartmontools). Ich lasse für meine HDs täglich einen Short-Test und wöchentlich einen Long-Test laufen.
Die notwendigen Laufzeiten der periodischen Prüfungen (scrub, smartctl, etc.) sind auf einem 24h bzw. dauerhaft/länger laufendem System ("Server") natürlich einfacher zu bewerkstelligen als bei einer "Workstation", auch die eigentlichen Vorteile von btrfs-raid greifen IMHO nur da. Man sollte diese Zeit für Tests/Wartung halt verfügbar machen.
Bei einer "Workstation", die ich ggf. 2-3 mal am Tag boote bzw. suspende, da würde ich persönlich wohl eher nicht auf Raid1 setzen wollen, bzw. ich sehe viele der eigentlichen Vorteile da flöten gehen (speziell auch was btrfs-raid betrifft). Ein "Grund": Festplatten geben nach meiner Erfahrung gerade immer beim/nach Einschalten/Anlaufen ihren Geist auf - mit 2 HDs im raid1 potenziere ich diese "Gefahr". Ich würde mir wahrscheinlich eher die 2. HD entweder extern bzw. eben nicht dauerhaft angeschlossen von Zeit zu Zeit "spiegeln/rsyn'en/etc." um beim Ausfall der einen die zweite aktivieren zu können. Also eher als "Backup" zu haben anstatt "Ausfallsicherheit" bei einer Workstation (die mir ausfallsicher nichts "liefern/servieren" müßte). Aber das sind eher "my 2 ct's...".