OMV - btrfs mount error nach Stromausfall

[Konfekt]

Hallo!

Nach einem Stromausfall habe ich mit meinem Selbstbau-NAS das Problem, dass der RAID nicht mehr eingebunden werden kann. Kurz die Infos zum NAS:

• OMV 5.6.26-1 Usul
• btrfs Dateisystem
• 4 Laufwerk-RAID Verbund, der nicht mehr eingebunden werden kann

Folgende Fehlermeldung erscheint:

Fehler #0:
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; mount -v --source '/dev/disk/by-id/md-name-myNAS:myNAS' 2>&1' with exit code '32': mount: /srv/dev-disk-by-label-data: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error. in /usr/share/php/openmediavault/system/process.inc:196
Stack trace:
#0 /usr/share/php/openmediavault/system/filesystem/filesystem.inc(742): OMV\System\Process->execute()
#1 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(942): OMV\System\Filesystem\Filesystem->mount()
#2 [internal function]: Engined\Rpc\OMVRpcServiceFileSystemMgmt->mount(Array, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('mount', Array, Array)
#5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1)
#6 {main}

Backup existiert, ist zwar nicht tagesaktuell, beinhaltet aber das Wesentliche. Da in den letzten Tagen einiges drauf kam und sich das Problem gestern ereignete, würde ich das Delta natürlich gern noch retten, wenn möglich. Ansonsten wäre der Verlust überschaubar, aber ärgerlich.

Für jede Hilfe dankbar.

 

[omavoss]

@Konfekt :
Es wäre vielleicht besser, Deine Fragen im OMV-Forum zu stellen:
https://forum.openmediavault.org/index.php?thread/8631-degraded-or-missing-raid-array-questions/
https://forum.openmediavault.org/index.php?board/11-raid/

Außerdem würde ich ein Upgrade auf OMV 6.x.x vorschlagen.

 

[Piktogramm]

Wenn du Ausgaben vom Terminal, Quellcode oder Vergleichbares hast nutze bitte die CODE Tags
https://www.computerbase.de/forum/help/bb-codes/

Wenn du irgendwelche Logs/Fehlermeldungen postest. Beschreibe genau, wie du an die herankommst. Nicht jeder ist auf allen Betriebssystemen/Distributionen flüssig.


/dev/md... weißt darauf hin, das OMV anscheinend mdadm fürs Raid nutzt. Also heck als erstes das Raid. Hier und bei allen anderen Terminalbefehlen, bitte dein Device ( /dev/...) einsetzen. :

bob@bob:~$ sudo mdadm -D /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sun Dec 17 02:21:49 2017
        Raid Level : raid5
        Array Size : 14650649600 (13971.95 GiB 15002.27 GB)
     Used Dev Size : 2930129920 (2794.39 GiB 3000.45 GB)
      Raid Devices : 6
     Total Devices : 6
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Thu Aug 11 06:44:32 2022
             State : clean
    Active Devices : 6
   Working Devices : 6
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

              Name : bob:0
              UUID : <removed>
            Events : 35032

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       81        1      active sync   /dev/sdf1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
       4       8       17        4      active sync   /dev/sdb1
       6       8       97        5      active sync   /dev/sdg1

Wenn bei "Persistence" irgendwas anderes steht als "Superblock is persistent", mach bitte NICHT weiter! Ebenso wenn bei einem der Laufwerke etwas anderes als "active sync" steht, bitte NICHT weiter machen!

Wenn das Raid in Ordnung ist, wäre dann Folgendes dran:

sudo btrfs rescue super-recover -v /dev/xxx

Und falls du im Netz suchst und hier jemand damit kommt, und sudo btrfs rescue zero-log /dev/xxx kommt. Das sollte bei halbwegs aktuellen Kerneln zum einen nicht nötig sein und zum Anderen besteht hier die Gefahr, dass hier die letzten 30s geschriebenen Daten vor dem Ausfall flöten gehen.

Edit: Ich hätte dein Problem im Linuxabteil des Forums geschrieben

 

[henfri]

Außerdem würde ich ein Upgrade auf OMV 6.x.x vorschlagen.

Aber nicht jetzt...

Falls du das Dateisystem neu anlegst/en musst, würde ich den MD RAID dringend weglassen und BTRFS den RAID verwalten lassen.
Davon abgesehen bin ich bei @Piktogramm

 

[Konfekt]

@omavoss

Dort habe ich mich auch schon erkundigt. Aus Erfahrung weiß ich, dass dort jedoch auf technisch hohem Niveau geantwortet wird, zumal hier der Austausch i.d.R. sehr schnell geschieht. In der Hoffnung auf möglichst rasche Hilfe habe ich es in beiden Foren versucht. Das nimmt mir hoffentlich niemand übel.

Das Upgrade auf 6.x nehme ich lieber erst dann vor, wenn ich das RAID habe retten können.

Ergänzung (11. August 2022)

@Piktogramm

Vielen Dank für Deine Anleitung. Folgendes bekam ich als Output (Persistent und active-sync war vorhanden):

parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
Ignoring transid failure
Couldn't setup extent tree
Failed to recover bad superblocks

Very bad news? Oder kann man da noch was beheben?

Ggf. kann das Thema verschoben werden?

 

[henfri]

Ich würde mir auf der BTRFS Mailingliste helfen lassen.

https://bbs.archlinux.org/viewtopic.php?id=248361 sieht nach einem ähnlichen Problem aus.
Aber wie gesagt: besser die Entwickler fragen.

 

[Piktogramm]

Aber nicht jetzt...

Falls du das Dateisystem neu anlegst/en musst, würde ich den MD RAID dringend weglassen und BTRFS den RAID verwalten lassen.

mdadm und BTRFS haben das selbe Problem was Raid 5/6 und "writeholes" angeht und sehr vergleichbare Lösungen dazu (zusätzliches Gefummel.. äh Konfguration nötig). Es ist daher fast egal was man an der Stelle nutzt. Will man das umgehen ist derzeit ZFS das Mittel der Wahl oder das (lange) Warten bis die Überarbeitung von BTRFS fertig wird.

parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
parent transid verify failed on 1470816927744 wanted 81678 found 81675
Ignoring transid failure
Couldn't setup extent tree
Failed to recover bad superblocks

Very bad news? Oder kann man da noch was beheben?

BTRFS ist recht robust und komplex. Nur weil die sanfteste Methode nicht auf Anhieb klappt, sind wir lange nicht am Ende. Am bitteren Ende kannst du immer noch versuchen datarecovery über alles drüber laufen zu lassen. Das wird hässlich (Dateinahmen und Pfade werden da nicht wiederhergestellt) aber möglich.

So weiter, die TransactionIDs haben bei dir eine minimale Differenz, daher sollte es klappen, das Dateisystem mit dem Backup des Dateisystembaums[1] zu mounten:

sudo mount -t btrfs -o -ro,usebackuproot /dev/mdxxx /ziel

Also nur lesend gemountet, als /ziel solltest du irgend einen leeren, sinnvollen Ordner wählen und dann kannst du alle Daten auf ein Backupmedium kopieren. Es fehlen dann aber (minimal) die letzten geschriebenen Daten und evtl. ist eine oder wenige Dateien kompromittiert. Ich würde also nicht empfehlen deine alten Backups zu überschreiben!

Wenn du sicher bist, dass du alles gesichert hast, würde ich die Btrfs Partition platt machen und neu erstellen und die Daten aus den Backups wiederherstellen.

Wenn "mount" nicht klappt geht es weiter.


[1] fürchterliche Übersetzung

 

[henfri]

mdadm und BTRFS haben das selbe Problem was Raid 5/6 und "writeholes" angeht und sehr vergleichbare Lösungen dazu (zusätzliches Gefummel.. äh Konfguration nötig). Es ist daher fast egal was man an der Stelle nutzt.

Mir ging es nicht um etwaige Bugs sondern darum dass
1) mdadm nicht nötig ist
2) mdadm unnötig Komplexität erzeugt
3) BTRFS RAID flexibler ist.

Und nicht um etwaige Bugs.

Du schlägst ja auch vor dass dateisystem neu aufzusetzen.
Würdest du ihm raten weiterhin mdadm zu nutzen?

 

[Piktogramm]

Ja aber nein

Ich weiß nicht was OMV als Standard vorsieht. Wenn die aktuelle Config das ist, was OMV macht, würde ich dabei bleiben, weil es im Zweifelsfall bei Updates und beim Monitorring mit den Mitteln von OMV langfristig die geringsten Komplikationen verspricht. Solang der @TE keine Anforderungen darüber hinaus formuliert, ordne ich das deutlich höher ein.

 

[henfri]

OMV wollte eigentlich mit v6 auf BTRFS -meines Wissens ohne mdadm umstellen.
Ist wohl jetzt auf v7 verschoben.

OMV unterstützt per se Beides. Aber um BTRFS zu nutzen muss man in Beiden Fällen an die Kommandozeile.

 

[Konfekt]

@Piktogramm

Bevor ich den Befehl ausführe, ich habe jetzt aktuell kein Medium zur Hand, auf welchem für das gesamte RAID rein vom verbrauchten Platz her freier Speicher verfügbar wäre. Das RAID bietet 12 TB und frei waren zuletzt wohl so um die 6 ungefähr, also müsste ich eine 6 TB Platte mindestens bereithalten, richtig?

Diese erst mal mounten, einbinden und als leeren Speicher dann zum Ziel machen?

 

[Piktogramm]

@Konfekt
Ne
Wenn Dateisysteme einhängt bzw. mountet braucht es keinen weiteren Speicher. Es braucht nur einen Pfad um das eingehängte Dateisystem einblenden zu können.

Beispiel:

# Als root den Ordner tmpbtrs in /media/ anlegen
sudo mkdir /media/tmpbtrfs
# Das Dateisystem auf md127 einhängen und unter tmpbtrfs/ einblenden
sudo mount -t btrfs -o ro,usebackuproot /dev/md127 /media/tmpbtrfs
# In tmpbtrfs springen
cd /media/tmpbtrfs
# Inhalte von tmpbtrfs auslisten, was theoretisch der Inhalt von deinem Speicher sein soll
ls

Zusätzlichen Speicher brauchst du dann "nur" um die gewünschten Dateien von tmpbtrfs zu sichern. Wenn du ein vollständiges Backup hast, ist das im besten Fall also nur der geänderte Teil.

 

[Konfekt]

@Piktogramm

Wahnsinn, hat funktioniert, ich komme über den Ordner /media/tmpbtrfs tatsächlich an die Daten heran. Zumindest sehe ich die Ordnerstruktur und die Dateien.

Dafür schon mal ein großes Danke!

Nun ist laut GUI /dev/md127 wieder eingebunden. Gibt es eine Methode, um diesen Ordner unter WIndows zugreifbar zu machen?

Vermutlich müsste ich dann /media/ per SMB einbinden und das unter Windows praktisch anmelden, oder weniger ratsam?
Sonst suche ich mir einen Weg, die besagten Daten per CLI zu kopieren, das sollte ja nicht zu schwer sein.

 

[Piktogramm]

Wenn du ein OMV-Share konfiguriert hast, solltest du mit mount und dessen Optionen das Raid auch an die Stelle einbinden können. Ich weiß nur nicht, wie die Konventionen von OMV an der Stelle sind. Typischerweise wäre aber, dass irgendwo unter /mnt/ oder /media/ der Speicher normalerweise eingehangen ist.

# Dateisystem aushängen, welches unter tmpbtrfs eingehangen ist
sudo umount /media/tmpbtrfs
# erneut mount, mit "richtigem" Ziel
mount <blablub> /pfad/vom/smbsshare

Theoretisch sollte das SMB-Share dann wieder (lesend) erreichbar sein. Da möge mir jemand widersprechen der mit OMV und SMB Ahnung hat

 

[Konfekt]

An dem Punkt hänge ich etwas, weil ich nicht genau weiß, was ich hier eintragen muss und auch nicht noch mehr zerschießen will, als schon ist.

Unter der GUI werden die SMB Freigaben nicht mehr richtig erkannt, weil der RAID nicht richtig eingebunden ist, da steht dann z.B. für eine Freigabe:

daten [on /dev/disk/by-label/data, daten/]

"Daten" verweist hier auf einen der Ordner im RAID und wurde als eine von mehreren Freigaben von mir in SMB erzeugt, so dass ich es als eigenes Netzlaufwerk unter Windows nutzen konnte, davon habe ich mehrere (Daten, Musik, Dokumente, etc.).

disk/by-label war vorher wohl korrekt bezeichnet.

 

[Piktogramm]

Schau mal unter /media/ wenn ich die OMV Doku[1] richtig verstehe, müsste es da weiter gehen und ein Ordner /media/dev existieren und in Konsequenz dann den Pfad: media/dev/disk/by-label/data
Das sollte das Ziel für mount sein.

Und kaputt machen kannst du nichts, solang mount mit "ro" also read-only erfolgt.

[1]https://openmediavault.readthedocs.io/en/5.x/administration/services/samba.html

Wenn das nicht richtig ist. Wünsche ich mir einmal den Inhalt von /etc/fstab

 

[henfri]

Hallo,

man kann in OMV nicht einen "Ordner" für Windows freigeben, sondern man muss erst eine Freigabe (/media/tmpbtrfs) erstellen. Diese kann man dann für Windows freigeben.

Also:
1) Freigegebenen Ordner im OMV GUI erstellen
2) Diesen freigegebenen Ordner unter Dienste -> SMB -> Freigabe für Windows verfügbar machen.

Aber erstmal einen Plan machen:
1) Willst du das Dateisystem platt machen?
2) Weißt du genau, welche Dateien im Backup fehlen?

Wenn beides "Ja", dann müsstest du die fehlenden Dateien irgendwo hinkopieren. dann ein neues Dateisystem erstellen, Backup zurück, fehlende Dateien zurück.

Ich denke aber, einfacher wäre das Dateisystem zu fixen. Es sei denn, du willst meinem Rat folgen und mdadm loswerden.

@Piktogram: Was ist deine Empfehlung zu (1)? Erstmal ist das Dateisystem ja noch readonly gemountet. Der Fehler ist also weiterhin da.


Gruß,
Hendrik

 

[snaxilian]

BTRFS den RAID verwalten

Keine gute Idee wenn es nicht gerade ein Raid 1 oder 0 werden soll und müsste es nicht das Raid sein, von das Redundant Array of independant Disks.
Btrfs hat viele gute Features aber Raid 5/6 gehört nicht dazu...

 

[henfri]

mdadm und BTRFS haben das selbe Problem was Raid 5/6 und "writeholes" angeht und sehr vergleichbare Lösungen dazu (zusätzliches Gefummel.. äh Konfguration nötig). Es ist daher fast egal was man an der Stelle nutzz

Aber ja:
Von BTRFS und RAID5/6 sollte man die Finger lassen.

Es ist aber auch zu vermuten dass sein Problem aus der Kombination mdadm RAID 5 und Stromausfall resultiert.

 

[Piktogramm]

@henfri
Der Stromfall bedingt es schon. Das liegt aber an der Stelle eher daran, dass BTRFS aus Performancegründen nur in größeren Zeitabständen Commits durchführt. Weswegen die TransactionIDs beim TE zwar auseinanderliegen aber nur mit einer kleinen Differenz.
Damit man das gefürchtete write hole trifft, müsste man (schreibende) Scrubs oder Restores laufen haben und zum gleichen Zeitpunkt ein Komplettausfall des Systems. Da nehmen sich mdadm und BTRFS gar nichts, die Mitigations sind die Selben. Das ist jeweils was für den fortgeschrittenen Kurs und regelmäßige Backups sind an der Stelle wichtiger.