Raid 5 btrfs - mount nicht möglich

[peterdermeter]

Hallo!

Ich habe leider ein großes Problem mit meiner NAS. Es befinden sich wichtige Daten auf dem Raid 5 Volume (bestehend aus 4 4TB Festplatten). Das Raid scheint in Ordnung zu sein, wohl eher ein Problem mit dem Dateisystem (btrfs). Hier mal ein paar logs. Ich hoffe, es kann mir jemand bei meinem Problem helfen (fingers crossed).

Spoiler: logs

root@Synology:/# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdb3[4] sda3[0] sdd3[3] sdc3[2]
11706589632 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
2097088 blocks [16/4] [UUUU____________]

md0 : active raid1 sdb1[1] sda1[0] sdc1[2] sdd1[3]
2490176 blocks [16/4] [UUUU____________]

unused devices: <none>


root@Synology:/# mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Feb 19 00:25:09 2022
Raid Level : raid5
Array Size : 11706589632 (11164.27 GiB 11987.55 GB)
Used Dev Size : 3902196544 (3721.42 GiB 3995.85 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

Update Time : Tue Sep 20 05:24:15 2022
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

Name : Synology:2 (local to host Synology)
UUID : 6e672b17:c399f51a:242c6c1d:dde0a6c6
Events : 195

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
4 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3



root@Synology:/# mdadm --examine /dev/sd[abcdfgjkl]3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6e672b17:c399f51a:242c6c1d:dde0a6c6
Name : Synology:2 (local to host Synology)
Creation Time : Sat Feb 19 00:25:09 2022
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 7804393120 (3721.42 GiB 3995.85 GB)
Array Size : 11706589632 (11164.27 GiB 11987.55 GB)
Used Dev Size : 7804393088 (3721.42 GiB 3995.85 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=32 sectors
State : clean
Device UUID : d9ec98d8:b45141af:f462d149:4d76ab81

Update Time : Tue Sep 20 05:24:15 2022
Checksum : 62e323f1 - correct
Events : 195

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6e672b17:c399f51a:242c6c1d:dde0a6c6
Name : Synology:2 (local to host Synology)
Creation Time : Sat Feb 19 00:25:09 2022
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 7804393120 (3721.42 GiB 3995.85 GB)
Array Size : 11706589632 (11164.27 GiB 11987.55 GB)
Used Dev Size : 7804393088 (3721.42 GiB 3995.85 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=32 sectors
State : clean
Device UUID : 5d8e0aa4:77ea075c:1f5f82c2:83328f24

Update Time : Tue Sep 20 05:24:15 2022
Checksum : f6b0169c - correct
Events : 195

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6e672b17:c399f51a:242c6c1d:dde0a6c6
Name : Synology:2 (local to host Synology)
Creation Time : Sat Feb 19 00:25:09 2022
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 7804393120 (3721.42 GiB 3995.85 GB)
Array Size : 11706589632 (11164.27 GiB 11987.55 GB)
Used Dev Size : 7804393088 (3721.42 GiB 3995.85 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=32 sectors
State : clean
Device UUID : 324b4583:5f37008d:e427ca9f:5d512753

Update Time : Tue Sep 20 05:24:15 2022
Checksum : 12c307f7 - correct
Events : 195

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6e672b17:c399f51a:242c6c1d:dde0a6c6
Name : Synology:2 (local to host Synology)
Creation Time : Sat Feb 19 00:25:09 2022
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 7804393120 (3721.42 GiB 3995.85 GB)
Array Size : 11706589632 (11164.27 GiB 11987.55 GB)
Used Dev Size : 7804393088 (3721.42 GiB 3995.85 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=32 sectors
State : clean
Device UUID : 206d03c7:1e3cc959:d65b66b8:7292632b

Update Time : Tue Sep 20 05:24:15 2022
Checksum : 1422a3ac - correct
Events : 195

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)



root@Synology:/# fdisk -l /dev/sda
Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: BDB8107A-B233-4B4D-9E4A-9D3A029907E7

Device Start End Sectors Size Type
/dev/sda1 2048 4982527 4980480 2.4G Linux RAID
/dev/sda2 4982528 9176831 4194304 2G Linux RAID
/dev/sda3 9437184 7813832351 7804395168 3.6T Linux RAID


root@Synology:/# fdisk -l /dev/sdb
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CC145BDD-ABF7-4504-BE4C-6623573F8BB2

Device Start End Sectors Size Type
/dev/sdb1 2048 4982527 4980480 2.4G Linux RAID
/dev/sdb2 4982528 9176831 4194304 2G Linux RAID
/dev/sdb3 9437184 7813832351 7804395168 3.6T Linux RAID


root@Synology:/# fdisk -l /dev/sdc
Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 61F6E2C2-297E-49F9-8AED-F48EC604C303

Device Start End Sectors Size Type
/dev/sdc1 2048 4982527 4980480 2.4G Linux RAID
/dev/sdc2 4982528 9176831 4194304 2G Linux RAID
/dev/sdc3 9437184 7813832351 7804395168 3.6T Linux RAID


root@Synology:/# fdisk -l /dev/sdd
Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B07CD483-B080-4BC9-B05B-72A0AB14ED63

Device Start End Sectors Size Type
/dev/sdd1 2048 4982527 4980480 2.4G Linux RAID
/dev/sdd2 4982528 9176831 4194304 2G Linux RAID
/dev/sdd3 9437184 7813832351 7804395168 3.6T Linux RAID



root@Synology:/# ls /dev/sd*
/dev/sda /dev/sda3 /dev/sdb2 /dev/sdc1 /dev/sdd /dev/sdd3
/dev/sda1 /dev/sdb /dev/sdb3 /dev/sdc2 /dev/sdd1
/dev/sda2 /dev/sdb1 /dev/sdc /dev/sdc3 /dev/sdd2



root@Synology:/# mount -v /dev/md2 /volume1
mount: wrong fs type, bad option, bad superblock on /dev/md2,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.


root@Synology:/# dmesg | tail
[59664.120856] BTRFS error (device md2): parent transid verify failed on 197533925376 wanted 37682 found 37282
[59664.134634] parent transid verify failed on 197533925376 wanted 37682 found 37282
[59664.144316] parent transid verify failed on 197533925376 wanted 37682 found 37282
[59664.152482] parent transid verify failed on 197533925376 wanted 37682 found 37282
[59664.152485] BTRFS error (device md2): BTRFS: md2 failed to repair parent transid verify failure on 197533925376, mirror = 2

[59664.166292] BTRFS error (device md2): failed to load usrquota subtree 257, ret=-5
[59664.174187] BTRFS error (device md2): usrquota disabled due to faield to load tree

[59664.197319] BTRFS: open_ctree failed

Bin wirklich für jede Hilfe dankbar. Bitte schreiben, falls weitere logs nötig sind.

 

[honky-tonk]

https://stackoverflow.com/questions/46472439/fix-btrfs-btrfs-parent-transid-verify-failed-on

ich denke parent transid verify failed ist der hauptfehler

aber wo liegt das problem? fährt es nicht hoch oder wirft es fehler in der oberfläche?

backups der wichtigen daten sind ja sicher vorhanden?!

 

[madmax2010]

Bitte hab ein Backup und spiel es ein.
Du nutzt ein experimentelle, instabiles Feature.

https://btrfs.wiki.kernel.org/index.php/Status
Probier mal das da, aber hab nicht zu viel Hoffnung
https://stackoverflow.com/questions/46472439/fix-btrfs-btrfs-parent-transid-verify-failed-on

 

[honky-tonk]

Du nutzt ein experimentelle, instabiles Feature.

von welchem feature redest du?

 

[PHuV]

Packe das Log mal bitte in einen Spoiler.

 

[madmax2010]

Raid 5

 

[taockoao]

Der Typ ist etwas selber schuld...

wie madmax schreibt, backupeinspielen und fertig. ambesten raid1 oder 10 machen.

 

[Garmor]

von welchem feature redest du?

Raid in Btrfs ist experimentell, aber die Synology wird doch sicher ihr eigenes Fake-Raid benutzen.

 

[peterdermeter]

https://stackoverflow.com/questions/46472439/fix-btrfs-btrfs-parent-transid-verify-failed-on

ich denke parent transid verify failed ist der hauptfehler

aber wo liegt das problem? fährt es nicht hoch oder wirft es fehler in der oberfläche?

backups der wichtigen daten sind ja sicher vorhanden?!

Die Synology fährt hoch, allerdings meldet es, dass das Volume abgestürzt. Auf die Daten habe ich leider keinen Zugriff. Die wichtigsten Daten, sprich Dokumente, haben ein Backup. Andere Daten, die mir auch wichtig sind (Fotos, Videos, Bücher) leider nicht. Ich hoffe auf eure Hilfe, dass ich das noch iwie retten kann.

 

[PHuV]

Geh auf Kommandozeile und führe die Schritte im Link von @madmax2010 aus.
https://stackoverflow.com/questions/46472439/fix-btrfs-btrfs-parent-transid-verify-failed-on

additional information

1. the btrfs mount became read only
2. btrfs-scrub failed with ERROR: scrubbing /dev/md124p2 failed for device id 1: ret=-1, errno=5

I solved it by deleting the nfs export ie. from /etc/export/ and then remounting the volumes and voila everything became ok

First run this command:
sudo btrfs rescue super-recover -v /dev/sda2
If it tells you “All supers are valid, no need to recover”, you need to run the following command to clear the filesystem log tree:
sudo btrfs rescue zero-log /dev/sda2
Now you should be able to mount your Btrfs file system.

t seems the only solution is to restore the data to another disk by

btrfs restore /dev/sda4 /mnt/anotherdisk/folder

 

[NobodysFool]

Raid in Btrfs ist experimentell, aber die Synology wird doch sicher ihr eigenes Fake-Raid benutzen.

Ja, bei Synology läuft das in getrennten Ebenen voneinander. BTRFS wird erst on-the-top auf das bestehende RAID draufgesetzt. Es werden NICHT die RAID-Features von BTRFS selbst genutzt.

Ich nutze RAID-6, bzw. das proprietäre SHR2 seit 2014 in der DS1813+ und seit letztem Jahr in der DS1821+, und das läuft butterweich und völlig problemlos. Auch Rebuilds durch hinzufügen neuer Platten, Ersatz durch größere und Erweiterung des Volumes, sowie Ersatz defekter Platten habe ich alles schon mehrmals problemlos durch.

 

[andy_m4]

Ja, bei Synology läuft das in getrennten Ebenen voneinander. BTRFS wird erst on-the-top auf das bestehende RAID draufgesetzt. Es werden NICHT die RAID-Features von BTRFS selbst genutzt.

Ich find' das ja ganz spannend. Da nimmt man schon extra ein Dateisystem was einen integrierten Volume-Manager/RAID hat und wirft diesen Teil dann aber weg. Und dann frag mich dann immer, warum die nicht einfach ZFS nehmen.

 

[Garmor]

Und dann frag mich dann immer, warum die nicht einfach ZFS nehmen.

Weil sie die Kisten dann nicht mit 2GB RAM verkaufen könnten.

 

[andy_m4]

Weil sie die Kisten dann nicht mit 2GB RAM verkaufen könnten.

ZFS läuft nicht mit 2GB RAM?
Um wie viel ist den Btrfs sparsamer verglichen mit ZFS?

 

[PHuV]

Und dann frag mich dann immer, warum die nicht einfach ZFS nehmen.

Wegen Lizenzproblemen? Es ist ja auch nicht im Linux Kernel, siehe Linus Torvalds erteilt ZFS im Linux-Kernel erneute Absage. Da Synology eh nur ein angepaßtes Linux verwendet, ist das vielleicht die Ursache.

 

[andy_m4]

Wegen Lizenzproblemen?

Welche Lizenzprobleme? :-)

Da Synology eh nur ein angepaßtes Linux verwendet, ist das vielleicht die Ursache.

Und wie machen das dann andere Linux-basierte NAS mit ZFS ?

Linus Torvalds erteilt ZFS im Linux-Kernel erneute Absage

Linus mag ein guter Techniker sein. Zu Rechtsfragen würde ich ihm aber nur eingeschränkt Expertise zusprechen. :-)

 

[PHuV]

Na ja, so ganz einfach ist es nun auch nicht mit CDDL, GPL, GPLv2 und Co. Das kann schon ein Minenfeld werden, wie im Artikel beschrieben. Das Problem mit Klagen ist ja nicht die Klage selbst, sondern mit den daraus errechneten Kosten. Wenn man da kein großer reicher Konzern ist, hat man da bei einer potentiellen Milliardenklage schnell verkackt.

 

[andy_m4]

Das kann schon ein Minenfeld werden, wie im Artikel beschrieben.

Der Artikel beschreibt das Szenario: Oracle kommt an und verklagt Leuten die ZFS mit Linux verwenden.
Und das ist halt auch der Grund warum ich sagte, das man Torvalds in Rechtsfragen wohl eher nicht zu Rate ziehen sollte. Weil die CDDL ist gar nicht das Problem, sondern eine potentielle Verletzung der GPL. Wenn es also zu einer Klage kommen sollte, dann eher nicht aus Richtung Oracle, sondern eher von irgendwelchen GPL-Taliban (z.B.: in Form der gplviolations oder so).

Das Problem mit Klagen ist ja nicht die Klage selbst, sondern mit den daraus errechneten Kosten.

Naja. Die Kosten dürften sich im Rahmen halten. Denn Entschädigungssummen a-la "entgangener Gewinn" oder so fallen ja schon mal weg. Urteile bezüglich GPL haben i.d.R. die Folge, das das verklagte Unternehmen das halt künftig sein lassen soll.

Aber ja. Das Argument "rechtliche Unwägbarkeiten" kann man durchaus gelten lassen. :-)

 

[snaxilian]

Du nutzt ein experimentelle, instabiles Feature.

Der Typ ist etwas selber schuld...

Ihr zwei glänzt aber nicht gerade mit Lesekompetenz, oder?

haben ein Backup. Andere Daten, die mir auch wichtig sind (Fotos, Videos, Bücher) leider nicht.

Tut mir leid aber offensichtlich sind die Fotos, Videos, Bücher ganz eindeutig keine wichtigen Daten. Von wichtigen Daten hat man Backups. Gerade weil du von anderen Daten ein Backup hast, muss es ja eine bewusste Entscheidung gewesen sein, für Fotos, Videos und Bücher explizit kein Backup eingerichtet zu haben, aus welchen Gründen auch immer.

Anyway: Das Raid an sich ist anhand deiner Befehle als intakt anzusehen, das Problem liegt also bei btrfs. Ein sinnvoller Lösungsansatz wurde dir ja in #3 bereits gepostet, du musst natürlich /dev/sda2 an deine Situation anpassen.

@peterdermeter Noch ein paar zusätzliche Ratschläge:
1. Best Practice ist in so einem Fall eigentlich Images der beteiligten Disks zu ziehen damit man, falls ein Rettungsversuch fehl schlägt, jederzeit zum Ausgangspunkt zurück kehren kann. Ja, das bedeutet erst einmal Geld ausgeben.
2. Nicht blind Befehle aus dem Internet abtippen sondern zuerst nachvollziehen, was diese Befehle machen und vor allem korrekt an die eigene Situation anpassen wo dies notwendig ist.
3. Du solltest dir dringend ein besseres Backupkonzept überlegen und vor allem auch umsetzen.
4. Backups sind gut aber noch besser ist es, wenn man diese auch erfolgreich zurück spielen kann. Im besten Fall hat man das 1-2 mal mit etwas zeitlichem Abstand erfolgreich ausprobiert damit man im Fehlerfall, so wie jetzt, entspannter an die Situation heran gehen kann weil man nicht erst dann heraus finden muss ob ein erfolgreicher Restore überhaupt klappt.

@andy_m4 Ach komm das sollte doch offensichtlich sein warum Synology so handelt, mal von der Lizenzthematik abgesehen. So können sie die Flexibilität von ihrem SHR mit den Snapshots & Scrubs von btrfs kombinieren ohne den SHR Part auf den Volumemanager von btrfs portieren zu müssen falls überhaupt sinnvoll und möglich. Zielgruppe von Synology sind Endkunden und diese wünschen offenbar Flexibilität. Außerdem ist SHR afaik älter und so musste Synology nur btrfs als zusätzliches Dateisystem einführen und spart sich so den Aufwand, seinen Kunden erklären zu müssen warum sie kein Raid 5/6 mit btrfs nativ nutzen können. Aus technischer Sicht mag das ggf. fragwürdig sein aber aus usability Sicht ein mMn akzeptabler Kompromiss.