Hi Ich versuche gerade, eine SSD die in einem Synology NAS verbaut war, unter Ubuntu zu lesen. Soweit ich mich erinnern kann, war die Partition als btrfs formatiert. Irgendwie schaff ich es aber nicht, die Partition zu mounten...
Angehängte Dateien:
Wie man sieht war sda3 Teil eines MD Raid1. Wenn noch kein md-Device existiert, musst du es mit mdadm erst zusammenstellen. Da du nur einen Teil des Spiegels hast wirst du es im degraded Status erstellen müssen.
Flo schrieb: > Irgendwie schaff ich es aber nicht, die Partition zu mounten Die Fehlermeldung schaut danach aus, als würde dir irgenein Paket für die btrfs-Unterstützung fehlen. Oder als wäre das btrfs auf der Disk in einer inkompatiblen (zu neuen) Version formatiert. Für ersters: Installier mal btrfs-progs etc nach. Für zweiteres: Was sagt "dmesg" nach dem mount-versuch?
:
Bearbeitet durch User
Εrnst B. schrieb: > Die Fehlermeldung schaut danach aus, als würde dir irgenein Paket für > die btrfs-Unterstützung fehlen. /dev/md3 gehört zu einem RAID, nutzbar mit mdadm – mit btrfs hat das an dieser Stelle nix zu tun. Im Log steht in diesem Fall auch nix anderes, als in der im Bild gezeigten Ausgabe: „wrong fstype, […] on /dev/md3“ Was zu tun ist, hat seere geschrieben.
seere schrieb: > Wie man sieht war sda3 Teil eines MD Raid1. Wenn noch kein > md-Device > existiert, musst du es mit mdadm erst zusammenstellen. Da du nur einen > Teil des Spiegels hast wirst du es im degraded Status erstellen müssen. das hat mich auch etwas verwundert, da die SSD immer allein verwendet wurde, d.h. nie Teil eines Raid Verbunds war...
Jack V. schrieb: > /dev/md3 gehört zu einem RAID, nutzbar mit mdadm – mit btrfs hat das an > dieser Stelle nix zu tun. Ja, aber das Raid ist ja schon aufgebaut und zugreifbar. Sonst hätte "btrfs filesystem show" nicht auf md3 zugreifen können um dort die Dateisystem-Header incl. UUID auszulesen. Das Problem muss also dahinter liegen. Ein "cat /proc/mdstat" oder "lsblk" kann Klarheit bringen. Flo schrieb: > das hat mich auch etwas verwundert, da die SSD immer allein verwendet > wurde, d.h. nie Teil eines Raid Verbunds war... Könnte mir denken, dass das NAS die Platten immer erst einmal durch ein md-Device schickt. Macht die verwaltung einfacher, weil's immer der gleiche Aufbau ist, und spätere Erweiterungen (zweite Platte als Spiegel, Hot-Replace, erweiterung zu echtem Raid usw) sind nachher unterbrechungsfrei möglich. Auch hier: "cat /proc/mdstat" erzählt die Geschichte.
:
Bearbeitet durch User
Flo schrieb: > das hat mich auch etwas verwundert, da die SSD immer allein verwendet > wurde, d.h. nie Teil eines Raid Verbunds war... Möglicherweise verwendet Synology des Schemas wegen unabhängig von der Anzahl Disks immer mdraid.
Εrnst B. schrieb: > Sonst hätte "btrfs filesystem show" nicht auf md3 zugreifen können um > dort die Dateisystem-Header incl. UUID auszulesen. Habe ich in der Tat überlesen – ist halt schade, dass die Meldungen als Bild gepostet worden sind. Dazu passt allerdings weder die Ausgabe von lsblk, noch das Verhalten von mount. Die btrfs-progs hingegen müssen ja bereits installiert sein, denn ›btrfs‹ ist offensichtlich vorhanden und funktionsfähig.
Vielleicht ist das btrfs Modul nicht geladen und wird nicht gefunden? Mach mal "cat /proc/filesystems", ist btrfs da aufgelisted? Funktioniert ein "modprobe btrfs"? Falls nicht, wenn du mit "lsmod" nachsiehst, kann es sein, dass eventuell gar keine Module geladen sind? Dann mal nachsehen, mit "uname -a", welche Kernelversion das ist, und mit "ls /lib/modules/" (oder war es /use/lib/modules/? weiss nicht mehr auswendig). Falls die nicht zusammenpassen, wird wohl beim Installieren des Kernels was schief gelaufen sein. Vermutlich wurde dann der Kernel nicht dort abgelegt, von wo das System ihn ladet, wodurch ein alter Kernel geladen wird. Und falls die Module davon auch noch schön weggeräumt wurden, weil man ja einen neuen kernel hat, dann kann sowas passieren. Ist alles nur eine Vermutung, aber das würd ich mal nachprüfen.
hmmm... nach dem mount Versuch gibt dmesg folgends aus:
1 | [ 163.671304] BTRFS critical (device md3): corrupt leaf: root=1 block=33062912 slot=56, invalid root flags, have 0x400000000 expect mask 0x1000000000001 |
2 | [ 163.671310] BTRFS error (device md3): block=33062912 read time tree block corruption detected |
3 | [ 163.671713] BTRFS critical (device md3): corrupt leaf: root=1 block=33062912 slot=56, invalid root flags, have 0x400000000 expect mask 0x1000000000001 |
4 | [ 163.671718] BTRFS error (device md3): block=33062912 read time tree block corruption detected |
5 | [ 163.707470] BTRFS error (device md3): open_ctree failed |
Das merkwürdige ist, dass die SSD im Synology immer problemlos funktioniert hat..
Ohje. Schaut so aus als würde Synology ein eigenen, inkompatibel gepatchten Branch von btrfs verwenden. Hier siehst du die unter Linux gültigen Feature-Flags: https://github.com/torvalds/linux/blob/master/include/uapi/linux/btrfs.h#L280 0x400000000 ist da nicht dabei. d.H. Synology hat btrfs wohl um eigene Features (& Flags) erweitert.
Kann es sein, das btrfs nicht byte-order neutral ist, somit die Disk einer big-endian Synology nicht an einem little-endian PC läuft?
Auch hier ist die byte-order ein Thema. Bitte Warnung beachten. https://www.synology-wiki.de/index.php/Datenrettung_von_Raid-Systemen_unter_Linux
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.