Ich habe mein Problem ursprünglich in der Gruppe
geschildert, bin aber zu der Überzeugung gekommen, dass mein Problem in dieser Gruppe besser aufgehoben ist. Zudem habe ich neue Erkenntnisse gewonnen, die ich im Folgenden schildern möchte.
Nachdem eine Partition eines Raid 5, welches ich in YaST 2 erstellt und mit BTRFS formatiert habe, ausgefallen ist, versuche ich dieses FS wieder ans Laufen zu bekommen.
Das Raid besteht aus 4 Platten der Größe 1TB.
Meine Analyse ergab foldendes:
Wenn ich das Raid durch
mdadm --create /dev/md0 --level=5 --raid-devices=4 --chunk=128 /dev/sda1 /dev/sdb1 /dev/sdc1 missing --assume-clean
neu zusammenbaue, wird der Superblock an den Stellen 0x10.000, 0x4.000.000 und 0x4.000.000.000 nicht gefunden. Mein Versuche, dies duurch geschickt gewählte Chunk-Größen in Ordnung zu bringen, habe ich bereits in der Server-Gruppe geschildert.
Ich stellte dann mittels
die verlorengegangene Partition wieder her, jedoch scheiterte auch der Versuch, die Chunk-Größe dadurch herauszufinden, dass ich untersuche, wo ASCII-Text oder z.T. leere Blöcke nebeneinander lagen, um zu sehen, an welchen Positionen die durch XOR entstandenen Paritätsblöcke liegen könnten. Es kam immer nur heraus, dass es die neu hinzugefügte Partition sdd1 sein muss.
Dann hatte ich Glück, dass in der ältesten noch gespeicherten Log-Datei von Yast2 der folgende Eintrag zu finden war:
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(SystemCmd):135 constructor SystemCmd(</usr/bin/stat --formatsd %f /dev/md0>)
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(execute):376 SystemCmd Executing:"/usr/bin/stat --format %f /dev/md0"
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(execute):377 timestamp [2170751.079253], 2025-05-05 13:00:23 GMT, 2025-05-05 15:00:23 CEST
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(step_fork_and_exec):487 child_pid:24362
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(add_line):713 line stdout[0] '61b0'
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(step_wait):615 child_retcode:0
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] SystemCmd.cc(execute):383 stopwatch 0.005891s for "/usr/bin/stat --format %f /dev/md0"
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] CmdStat.cc(CmdStat):42 path:/dev/md0 mode:25008
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(reload):72 loading file /proc/mdstat
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):150 content of /proc/mdstat
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):153 Personalities : [raid0]
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):153 md0 : active raid0 sdb1[1] sdd1[3] sdc1[2] sda1[0]
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):153 4294967040 blocks super 1.0 64k chunks
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):153
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] AsciiFile.cc(log_content):153 unused devices: <none>
2025-05-05 15:00:23 <1> rebzdu(24195) [libstorage] ProcMdstat.cc(parse):63 data[md0] -> md-level:RAID0 super:1.0 chunk-size:65536 size:4398046248960 devices:</dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1>
Alles anzeigen
Da die Info zu lang ist, muss ich ein zweiteiliges Posting daraus machen.