Mittlerweile durfte das BTRFS RAID 1 auf meinem Laptop seine Selbstheilungskräfte unter Beweis stellen (siehe Wieso haben moderne Laptops eigentlich einen mSATA-Slot?). Bei einem Schrubben erhielt ich:
|
1 2 3 4 5 6 |
merkaba:~> btrfs scrub status /home scrub status for [eine UUID] scrub started at Thu Oct 9 15:52:00 2014 and finished after 564 seconds total bytes scrubbed: 268.36GiB with 60 errors error details: csum=60 corrected errors: 60, uncorrectable errors: 0, unverified errors: 0 |
Meine erste Reaktion war „Oha!“, doch dann machte ich mir nochmal bewusst was „corrected“ heißt. Nun interessierte mich natürlich, auf welcher SSD die Fehler auftraten:
|
1 2 3 4 5 6 7 8 9 10 11 |
merkaba:~> btrfs device stats /home [/dev/mapper/msata-home].write_io_errs 0 [/dev/mapper/msata-home].read_io_errs 0 [/dev/mapper/msata-home].flush_io_errs 0 [/dev/mapper/msata-home].corruption_errs 60 [/dev/mapper/msata-home].generation_errs 0 [/dev/mapper/sata-home].write_io_errs 0 [/dev/mapper/sata-home].read_io_errs 0 [/dev/mapper/sata-home].flush_io_errs 0 [/dev/mapper/sata-home].corruption_errs 0 [/dev/mapper/sata-home].generation_errs 0 |
Also die neue Crucial m500 mSATA SSD. Die Intel SSD 320 hatte aber noch eine gute Kopie, daher konnte BTRFS den Fehler beheben. Das macht es bei einem Scrub oder bereits ab Kernel 3.2 bei einem Lesezugriff auf die Daten (siehe auch BTRFS Wiki: Änderungen nach Funktion).
Für Daten, bei denen das mit dem automatischen Reparieren nicht klappt, ist natürlich gut zu wissen, welche Datei betroffen ist. Da hilft das Kernel-Log. Ein Auszug:
|
1 2 3 4 5 6 |
Oct 9 16:00:25 merkaba kernel: [27756.060625] BTRFS: checksum error at logical 492204511232 on dev /dev/mapper/msata-home, sector 307349096, root 256, inode 8654114, offset 0, length 4096, links 1 (path: .ms/ECRYPTFS_FNEK_ENCRYPTED.[…] Oct 9 16:00:25 merkaba kernel: [27756.060630] BTRFS: checksum error at logical 492204380160 on dev /dev/mapper/msata-home, sector 307348840, root 256, inode 8654104, offset 0, length 4096, links 1 (path: .ms/ECRYPTFS_FNEK_ENCRYPTED.[…] Oct 9 16:00:25 merkaba kernel: [27756.060651] BTRFS: bdev /dev/mapper/msata-home errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 Oct 9 16:00:25 merkaba kernel: [27756.060655] BTRFS: bdev /dev/mapper/msata-home errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 Oct 9 16:00:25 merkaba kernel: [27756.096398] BTRFS: fixed up error at logical 492204380160 on dev /dev/mapper/msata-home Oct 9 16:00:25 merkaba kernel: [27756.096554] BTRFS: fixed up error at logical 492204511232 on dev /dev/mapper/msata-home |
Jetzt weiß ich zwar dank des über das Verzeichnis im BTRFS-Dateisystem gemounteten Dateisystems eCryptfs immer noch nicht, wie die Dateinamen nun unverschlüsselt heißen, bin aber dennoch in der Lage, genau diese Datei aus einem datei-basierten Backup herauszuziehen – was hier zum Glück nicht erforderlich ist.
Warum nun der Prüfsummen-Fehler auftrat? Ich habe nur eine Vermutung: Durch ein hartes Ausschalten konnte die mSATA SSD einige Daten nicht fertig schreiben – und ich wüsste nicht, wo auf der winzigen Platine ein Kondensator Platz hätte, um noch für eine kurze Zeit Strom zu liefern, um wie bei der Intel SSD 320 die Daten noch zu schreiben. Und meiner Erinnerung nach war da einige Tage davor etwas in der Art. Wie dem auch sei: Es gab seitdem keine neuen Fehler mehr, BTRFS hat die Fehler korrigiert und der Befehl smartctl -a oder smartctl -x melden auch keine Probleme – also lasse ich das erstmal so stehen, und beobachte weiterhin.
Somit verbleibe ich mit einem: Ha! Erster Blog-Artikel im neuen Jahr. Und einem (späten): Ein schönes und erfolgreiches neues Jahr!
Martin Steigerwald
Martin Steigerwald beschäftigt sich seit Mitte der 90er Jahre mit Linux. Er ist langjähriger Autor von Artikeln für verschiedene Computer-Magazine wie die LinuxUser (linuxuser.de) und das Linux-Magazin (linux-magazin.de). Seit Herbst 2004 ist er als Trainer für Linux-Themen bei Proact Deutschland in Nürnberg tätig.
