Kann BTFS Volume nicht mehr mounten

[Mr. Robot]

Hallo!

Während eines Rebalance von meinem BTFS RAID5 ist mir aufgefallen, dass eine Festplatte im sterben liegt. IO-Fehler, und liefert keine Smart-Werte mehr...
Ich hab dann ein 'btrfs balance cancel' abgesetzt, aber leider nicht gewartet bis er damit fertig ist, sondern die Kiste runter gefahren, um eine Ersatz-HD ein zu bauen. Seit dem kann ich das Volume nicht mehr mounten. (Auch nicht mit -o degraded)

System: openSUSE Leap 42.2 - Kernel 4.4.62 (64 bit), btrfs-progs v4.5.3
Der betroffene Pool besteht aus sechs HDs, die alle verschlüsselt sind. Teils mit Truecrypt, teils mit Fuse. BTFS greift also nur auf die Crypto-Mapper zu, aber das ist so weit wohl kein Problem.


Ich hab die Problem-HD mit dd_rescue geklont. Das ging so weit einwandfrei. Ich kann auch alle 6 HDs entschlüsseln. BTFS findet auch alle seine benötigten Devices:

c64:~ # btrfs filesystem show
Label: none  uuid: 95ba2b23-088e-4cc4-88a2-1af7dbf4a3d9
        Total devices 1 FS bytes used 188.17GiB
        devid    1 size 234.07GiB used 234.07GiB path /dev/mapper/system-root

Label: 'Datengrab'  uuid: f2aa3d0d-1d9b-4c3e-9229-59aa39e45f86
        Total devices 6 FS bytes used 9.86TiB
        devid    1 size 2.73TiB used 2.43TiB path /dev/mapper/truecrypt3
        devid    2 size 1.82TiB used 1.82TiB path /dev/mapper/truecrypt2
        devid    4 size 2.73TiB used 2.43TiB path /dev/mapper/truecrypt4
        devid    5 size 3.64TiB used 2.43TiB path /dev/mapper/truecrypt1
        devid    6 size 3.64TiB used 2.43TiB path /dev/mapper/luks1
        devid    7 size 931.51GiB used 930.71GiB path /dev/mapper/luks3

Das erste ist die System-SSD. Die läuft einwandfrei, und kann hier ignoriert werden.
'Datengrab' ist das Problemkind (Nomen es Omen...). So weit sieht die Ausgabe ja ganz ok aus.
(Dass Devid 3 fehlt, kommt daher, dass im Laufe der Zeit immer mal wieder HDs hinzu kamen/ raus genommen wurden. Das ist so weit ok)
Die geklonte HD ist übrigens devid 2 / truecrypt2.

Aber jetzt will ich mounten:

c64:~ # mount -o ro,recovery /dev/mapper/truecrypt1 /mnt/pool
mount: wrong fs type, bad option, bad superblock on /dev/mapper/truecrypt1,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.
c64:~ # dmesg | tail
[138943.406161] BTRFS error (device dm-9): parent transid verify failed on 79133986385920 wanted 1362492 found 1359837
[138943.577940] BTRFS error (device dm-9): parent transid verify failed on 78146504699904 wanted 1362471 found 1359813
[138943.780178] BTRFS error (device dm-9): parent transid verify failed on 79135957667840 wanted 1362506 found 1359776
[138943.873119] BTRFS error (device dm-9): parent transid verify failed on 79139057639424 wanted 1362405 found 1359534
[138943.990397] BTRFS error (device dm-9): parent transid verify failed on 79135311122432 wanted 1362492 found 1359838
[138944.098682] BTRFS error (device dm-9): parent transid verify failed on 79137625284608 wanted 1362472 found 1359785
[138944.127024] BTRFS error (device dm-9): parent transid verify failed on 79138357481472 wanted 1359952 found 1359786
[138944.155453] BTRFS error (device dm-9): parent transid verify failed on 79133730607104 wanted 1361324 found 1359837
[138944.230373] BTRFS: Failed to read block groups: -5
[138944.293838] BTRFS: open_ctree failed

Was ich bisher probiert habe (abgesehen vom klonen der kaputten HD):

c64:~ # btrfs rescue super-recover /dev/mapper/truecrypt1
All supers are valid, no need to recover

c64:~ # btrfs rescue zero-log /dev/mapper/truecrypt1
parent transid verify failed on 78878214270976 wanted 1362159 found 1161173
parent transid verify failed on 78878214270976 wanted 1362159 found 1161173
bytenr mismatch, want=78878214270976, have=78878214008832
Couldn't read chunk tree
ERROR: could not open ctree

c64:~ # btrfs rescue chunk-recover -yv /dev/mapper/truecrypt1
All Devices:
Device: id = 2, name = /dev/mapper/truecrypt2
Device: id = 7, name = /dev/mapper/luks3
Device: id = 6, name = /dev/mapper/luks1
Device: id = 4, name = /dev/mapper/truecrypt4
Device: id = 1, name = /dev/mapper/truecrypt3
Device: id = 5, name = /dev/mapper/truecrypt1

Scanning: 0 in dev0, 0 in dev1, 0 in dev2, 0 in dev3, 0 in dev4, 0 in dev5Segmentation fault (core dumped)
c64:~ # dmesg | tail
[138943.577940] BTRFS error (device dm-9): parent transid verify failed on 78146504699904 wanted 1362471 found 1359813
[138943.780178] BTRFS error (device dm-9): parent transid verify failed on 79135957667840 wanted 1362506 found 1359776
[138943.873119] BTRFS error (device dm-9): parent transid verify failed on 79139057639424 wanted 1362405 found 1359534
[138943.990397] BTRFS error (device dm-9): parent transid verify failed on 79135311122432 wanted 1362492 found 1359838
[138944.098682] BTRFS error (device dm-9): parent transid verify failed on 79137625284608 wanted 1362472 found 1359785
[138944.127024] BTRFS error (device dm-9): parent transid verify failed on 79138357481472 wanted 1359952 found 1359786
[138944.155453] BTRFS error (device dm-9): parent transid verify failed on 79133730607104 wanted 1361324 found 1359837
[138944.230373] BTRFS: Failed to read block groups: -5
[138944.293838] BTRFS: open_ctree failed
[139558.204408] btrfs[10597]: segfault at 7f8b5c033000 ip 00007f8b6caeac40 sp 00007f8b6b9bebf8 error 4 in libc-2.22.so[7f8b6c9c2000+19a000]

Jetzt bin ich an dem Punkt, an dem ich Hilfe gebrauchen könnte...

Von den wichtigsten Daten hab ich zwar ein Backup, aber es wäre schade um das ungesicherte TV&Filmarchiv.

 

[Hallo32]

Der BTRFS IRC Channel war des öfteren hilfreich.
Viel Erfolg.

 

[KAKTUSkiller]

Ich würde auch im IRC nachfragen, da bekommt man mit kompletten Informationen schnell Hilfestellungen. Unterdessen solltest du herausfinden, welches blockdevice "dm-9" ist. Dann weisst du schonmal wo du ansetzen kannst. Unter Umständen kann jetzt auf einer anderen Platte was im Argen liegen.

Im Wiki ist auch der Vorgang zum tauschen einer Platte beschrieben. MMn müsste die neue Platte vor dem Entfernen der Alten hinzugefügt werden.

E: Was war der Grund für den Rebalance?

 

[Piktogramm]

Das HDDs nicht auf SMART Anfragen reagieren aber anscheinend noch "irgendwie" reagieren und Daten ausgeben ist seltsam. Ich hatte mit einem Marvel 88SE9230 Sata Controller ein vergleichbares Problem. Da funktionierten Zugriffe auf die HDDs vergleichsweise problemlos. Jedoch sorgten SMART-Befehle zu sporadischen Problemen wie diesem mündete:

$ journalctl -p 0..4 | grep ata4.0                                                                                

Dec 20 00:37:04 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Dec 20 00:37:04 server kernel: ata4.00: failed command: IDENTIFY DEVICE                                                            
Dec 20 00:37:04 server kernel: ata4.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 20 pio 512 in                                  
Dec 20 00:37:04 server kernel: ata4.00: status: { DRDY }     
Dec 27 18:55:55 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Dec 27 18:55:55 server kernel: ata4.00: failed command: IDENTIFY DEVICE                                                            
Dec 27 18:55:55 server kernel: ata4.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 22 pio 512 in                                  
Dec 27 18:55:55 server kernel: ata4.00: status: { DRDY }     
Dec 28 02:25:10 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Dec 28 02:25:10 server kernel: ata4.00: failed command: SMART                                                                      
Dec 28 02:25:10 server kernel: ata4.00: cmd b0/d5:01:01:4f:c2/00:00:00:00:00/00 tag 21 pio 512 in                                  
Dec 28 02:25:10 server kernel: ata4.00: status: { DRDY }     
Mar 13 15:57:49 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Mar 13 15:57:49 server kernel: ata4.00: failed command: IDENTIFY DEVICE                                                            
Mar 13 15:57:49 server kernel: ata4.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 30 pio 512 in                                  
Mar 13 15:57:49 server kernel: ata4.00: status: { DRDY }     
Mar 16 19:56:39 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Mar 16 19:56:39 server kernel: ata4.00: failed command: IDENTIFY DEVICE                                                            
Mar 16 19:56:39 server kernel: ata4.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 9 pio 512 in                                   
Mar 16 19:56:39 server kernel: ata4.00: status: { DRDY }     
Mar 17 18:21:23 server kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen                                    
Mar 17 18:21:23 server kernel: ata4.00: failed command: IDENTIFY DEVICE                                                            
Mar 17 18:21:23 server kernel: ata4.00: cmd ec/00:01:00:00:00/00:00:00:00:00/40 tag 23 pio 512 in                                  
Mar 17 18:21:23 server kernel: ata4.00: status: { DRDY }     
Mar 17 23:58:05 server kernel: ata4.00: disabled

Das Schicksal der von dem Marvel Controler verwalteten HDDs sind auch immer gravierend schlechte SMART-Werte nach nur wenigen Betriebsstunden. Lustigerweise tauchen im Journal auch allerhand ata Devices auf, die es garnicht gibt (ein Controller mit 4 Anschlüssen der Fehler für ata8 wirft und den ata-Treiber so zum Abschmieren bringt -.-)

Bei mir hat nur geholfen verschiedene Firmwareversionen durchzuprobieren.

Das hilft zwar überhaupt nicht beim Widerherstellen der Daten, aber vielleicht beim Vermeiden zukünftiger Probleme.

 

[Mr. Robot]

Ich würde auch im IRC nachfragen, da bekommt man mit kompletten Informationen schnell Hilfestellungen. Unterdessen solltest du herausfinden, welches blockdevice "dm-9" ist. Dann weisst du schonmal wo du ansetzen kannst. Unter Umständen kann jetzt auf einer anderen Platte was im Argen liegen.

Puh, wo finde ich nochmal die Zuordnung für dm-9?

Im Wiki ist auch der Vorgang zum tauschen einer Platte beschrieben. MMn müsste die neue Platte vor dem Entfernen der Alten hinzugefügt werden.

Das austauschen geht aber leider von einem funktionierendem Dateisystem aus. Ich hätte es auch lieber direkt ohne klonen ausgetauscht.

E: Was war der Grund für den Rebalance?

Ich hatte das Gefühl, dass das Tempo nachlässt. Aber das lag dann wohl eher an der sterbenden Platte...

 

[KAKTUSkiller]

Puh, wo finde ich nochmal die Zuordnung für dm-9?

Ich hab bei mir nochmal nachgeschaut und habe gesehen, dass "dm-9" wahrscheinlich einfach das "Haupt-device" für das Volume ist. Ich selbst habe immer wieder Probleme mit einem Kabeladapter, wobei die Kommunikation mit einer Platte gestört ist (Datenkorruption), sieht ähnlich aus wie Piktogramm das beschreibt, was sich dann mit "BTRFS error (device dm-x): " im Kernellog bemerkbar macht. Bisher dachte ich fälschlicherweise, dass dies die betroffene Platte ist.

Beispiel:

# dmesg | grep dm-3
[35976.635120] BTRFS error (device dm-3): bdev /dev/mapper/cryptsda errs: wr 408516, rd 423524, flush 56, corrupt 3041393, gen 2496

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0   1.8T  0 disk
└─cryptsda  254:0    0   1.8T  0 crypt
sdb           8:16   0   3.7T  0 disk
└─cryptsdb  254:1    0   3.7T  0 crypt
sdc           8:32   1   1.8T  0 disk
└─cryptsdc  254:2    0   1.8T  0 crypt
sdd           8:48   1   1.8T  0 disk
└─cryptsdd  254:3    0   1.8T  0 crypt /srv/nfs/vault
sde           8:64   1 465.8G  0 disk
└─cryptsde  254:4    0 465.8G  0 crypt
mmcblk0     179:0    0   3.7G  0 disk
├─mmcblk0p1 179:1    0   300M  0 part  /boot
└─mmcblk0p2 179:2    0   3.4G  0 part  /home

# dmsetup ls
cryptsde        (254:4)
cryptsdd        (254:3)
cryptsdc        (254:2)
cryptsdb        (254:1)
cryptsda        (254:0)

Cryptsdd fungiert hier als Volume (dm-3) wobei der Fehler von sda (dm-0) kommt.


Zu deinem Problem:

Momentan bin ich überfragt, aber ich hoffe du hast dich schon im IRC gemeldet. Du könntest noch btrfs check ohne --repair versuchen (evtl. mit -p und/oder --mode lowmem wenn <= 4GB Ram):

btrfs check -p /dev/mapper/truecrypt3

Damit hättest du noch mehr Futter für Helfende. Mit der Option --repair besteht latente Gefahr von Datenverlust. Hat aber bei mir schon geholfen (Raid 1 Volume), kann auch nach hinten losgehen .

E: btrfs restore wäre auch eine Option die Daten ohne Backup zu sichern.

E2: Dir ist bewusst, dass der raid5/6 Modus nicht produktiv genutzt werden sollte?

 

[Mr. Robot]

Ok, jemand im IRC hat mein Dateisystem für FUBAR erklärt. Ein Kernel-Bug hat ihm wohl den Rest gegeben.

Dir ist bewusst, dass der raid5/6 Modus nicht produktiv genutzt werden sollte?

Ja. Aber ich hab nur damit gerechnet, mit einem read-only Dateisystem da zu sitzen, nicht mit einem Totalschaden.
Naja, shit happens.

 

[Piktogramm]

Seid ihr die Möglichkeiten von btrfs restore durchgegangen? Gerade sowas wie -u? Siehe Post #6

Ansonsten BTRFS mit einem 4.4 Kernel, ich würde auf Verdacht versuchen einen möglichst aktuellen Kernel zu nehmen (als auch neuere Versionen von btrfs-progs) in der Hoffnungen, dass die zahlreichen "misc. improvments" aus dem Changelog dein Problem ebenfalls betreffen.

 

[Mr. Robot]

Seid ihr die Möglichkeiten von btrfs restore durchgegangen? Gerade sowas wie -u? Siehe Post #6

Ja, bringt alles nichts, außer Fehlermeldungen.

Ansonsten BTRFS mit einem 4.4 Kernel, ich würde auf Verdacht versuchen einen möglichst aktuellen Kernel zu nehmen

Dafür sei es zu spät - 'death on write'.

Aber egal, Leben geht weiter.