-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
mdadm raid 5 keine superblocks mehr
- Ersteller error
- Erstellt am
A
Anonymous
Gast
hat er dir dazwischen ein leere Seite oder eine andere Ausgebe gebracht?
Eine Fehlermeldung hat er jedenfalls nicht gebracht, scheint nur mit der Ausgabeumleitung und dem pager bei dir nicht zu funktionieren.
Eigentlich sollte da eine neu Seite kommen die dein Grundverzeichnis unten anzeigt wird und wenn du "q" eingibst dann steht es so auf der Konsole wie du es hier reingesetzt hast.
robi
Eine Fehlermeldung hat er jedenfalls nicht gebracht, scheint nur mit der Ausgabeumleitung und dem pager bei dir nicht zu funktionieren.
Eigentlich sollte da eine neu Seite kommen die dein Grundverzeichnis unten anzeigt wird und wenn du "q" eingibst dann steht es so auf der Konsole wie du es hier reingesetzt hast.
robi
A
Anonymous
Gast
wenn du so nichts siehst, dann mach es mal interaktiv
PS.ich habe es geahnt, das mit dem Debugger ist im Forum kaum machbar. :???:
robi
Das roote sind deine Eingaben, das blaue die Ausgaben des Debuggers, dazwischen erscheinen noch Ausgaben die nach eingabe von q aber wieder verschwinden.
PS.ich habe es geahnt, das mit dem Debugger ist im Forum kaum machbar. :???:
robi
A
Anonymous
Gast
sollte eigentlich gleich kommen, warum den dritten, weil ich den gerade so schnell mit dem Taschenrechner ausrechnen konnte.error schrieb:die beiden seiten kamen für command 1 und 2. der 3te läuft. dauert wohl bei 3 terrabyte etwas
edit:
warum soll ich dann eigentlich den 3ten superblock nehmen? nur so interessehalber.
Normalerweise ist in allen das selbe, du solltest so einige 100 Stück davon auf dem Filesystem haben.robi
Code:
debian:~# debugfs /dev/md0 -s163840 -b4096 -R "stats"
debugfs 1.41.3 (12-Oct-2008)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 319ae1ff-5c87-4d2f-b1bd-4152e2bf1fbe
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 183148544
Block count: 732571872
Reserved block count: 36628593
Free blocks: 721025017
Free inodes: 183148533
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 849
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Thu Mar 12 16:37:19 2009
Last mount time: n/a
Last write time: Thu Mar 12 17:25:55 2009
Mount count: 0
Maximum mount count: 25
Last checked: Thu Mar 12 16:37:19 2009
Check interval: 15552000 (6 months)
Next check after: Tue Sep 8 17:37:19 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 65279f15-a0ab-433c-90f6-97ba97f48aae
Journal backup: inode blocks
Directories: 32256
Group 0: block bitmap at 1025, inode bitmap at 1026, inode table at 1027
31223 free blocks, 8181 free inodes, 2 used directories
Group 1: block bitmap at 33793, inode bitmap at 33794, inode table at 33795
31229 free blocks, 8192 free inodes, 0 used directories
Group 2: block bitmap at 65536, inode bitmap at 65537, inode table at 65538
32254 free blocks, 8192 free inodes, 0 used directories
Group 3: block bitmap at 99329, inode bitmap at 99330, inode table at 99331
31229 free blocks, 8192 free inodes, 0 used directories
Group 4: block bitmap at 131072, inode bitmap at 131073, inode table at 131074
32254 free blocks, 8192 free inodes, 0 used directories
Group 5: block bitmap at 164865, inode bitmap at 164866, inode table at 164867
31229 free blocks, 8192 free inodes, 0 used directories
Group 6: block bitmap at 196608, inode bitmap at 196609, inode table at 196610
32254 free blocks, 8192 free inodes, 0 used directories
Group 7: block bitmap at 230401, inode bitmap at 230402, inode table at 230403
31229 free blocks, 8192 free inodes, 0 used directoriesalso den nehm ich dann mal. drück die daumen
soll ich alles mit ja beantworten? oder muss ich was beneinen?
fsck.ext3 -b 163840 -B 4096 /dev/md0
A
Anonymous
Gast
alles immer mit "ja" oder einfach "ENTER"
"ja" ist voreingestellt.
robi
Achtung dass konnen einige hundert werden.
"ja" ist voreingestellt.
robi
Achtung dass konnen einige hundert werden.
ja ist zwar nicht voreingesllt, aber mit -y lass ich das mal laufen. wird wohl eine weile dauern. ich hoffe es bleibt am ende was bei übrig. wie sehen erfahrungsgemäß die chancen aus?
nebenbei, was passiert eigentlich, wenn so ein inode nicht in der richtigen gruppe ist und bereinigt wird. oder ein illegaler block gefunden wurde.
nebenbei, was passiert eigentlich, wenn so ein inode nicht in der richtigen gruppe ist und bereinigt wird. oder ein illegaler block gefunden wurde.
A
Anonymous
Gast
die Chancen sehen oft sehr gut aus, einige der letzten Änderungen oder Dateien die gerade angelegt wurden sind machmal weg. Gegen einige alte verschwunde Dateien oder Verzeichnisse die nicht in "lost&found" gelandet sind, könnte man mit genügend Hintergrundwissen auch noch was tun und das eine oder andere was fsck nicht mehr zusammensetzen konnte trotzdem noch recovern. Bräuchte man aber einige Daten auf dem eigenen PC und du dürftest mal ein paar Tage noch nicht drauf schreiben.error schrieb:
müsste man zB vor dem ersten Einhängen zum Schreiben mit folgendem Befehl eine Kopie des Filesystemjournals erstellen.
Code:
debugfs /dev/md0 -R "dump <8> dump.log"
Code:
e2image -r /dev/md0 - | bzip2 > md0.bz2Nach ein paar Tagen könnte ich dir dann sagen, welche Dateien noch zusätzlich zu retten währen und wie.
Aber im Moment geht das auch nicht, bin gerade beim kofferpacken und die nächsten paar Wochen unterwegs.
Code:
wenn so ein inode nicht in der richtigen gruppe ist und bereinigt wird. oder ein illegaler block gefunden wurde.illegaler Block, das sind zB Differenzen zwischen der Größe einer Datei und der Anzahl der Blöcke die die Datei derzeit belegt.
robi
A
Anonymous
Gast
was sind das für Dateien, kannst du ermitteln ob die zu kurz oder zu lang sind oder ob die intern verdreht sind.
Ist von der Anzahl der Dateien und Verzeichnisse wenigsten genügend da.
hattest du die Kombination "missing" sdb sdc sdd" auch getestet?
Kopien hattest du doch gemacht oder ?
robi
die dateien sind so wie es aussieht alle da. es sind auch alle nicht crc relevanten dateien lesbar und haben immer nur kleine fehler im bild (fotos, videos). archive kann ich nicht öffnen.
backups habe ich keine gemacht, da ich den platz dazu nich zusammen bekommen habe. eine andere missing variante hatte ich nicht ausprobiert.
backups habe ich keine gemacht, da ich den platz dazu nich zusammen bekommen habe. eine andere missing variante hatte ich nicht ausprobiert.
A
Anonymous
Gast
Das sieht natürlich weniger gut aus. Defekte komprimierte Archive gehen eventuell nur noch zu öffen und zu entpacken bis zum ersten CRC Fehler. Bei meinen früheren Tests habe ich hinter einem Fehler in der Kompression danach nichts vernünftiges mehr zusammenbekommen. Versuchen könnte man zB bei gzip komprimierten tar zB.
dieses "recover" dann versuchen mit tar auspacken. hierbei würde eventuell. ein kleines Perl Script noch helfen eventuell noch funktionierende Tardateien hinter den Fehler zu finden. "find_tar_headers.pl" (mal im Internet danach suchen)
Infos wie man sowas machen kann gibts dazu zB hier http://oss.bestsolution.at/bash/repair_tar_archives.html.de.
robi
Code:
zcat archiv.gz > recoverInfos wie man sowas machen kann gibts dazu zB hier http://oss.bestsolution.at/bash/repair_tar_archives.html.de.
robi
naja, ich rechne schon damit, das alles zu verwerfen. ich lasse jetzt noch ein paar mal fsck drüber laufen, der findet noch paar sachen. solange bis er nix mehr findet und danach werde ich sehen, was übrig geblieben ist. aber danke für die mühevolle hilfe. ich werde berichten, was bei raus kam
so, ich hab mindestens 20 mal mit allen verschiedenen superblöcken das dateisystem prüfen lassen, immer gibts was zu korrigieren, aber nie bessert sich was. und auf dem primären superblock heisst es sogar "sauber". hab den mit force mal laufen lassen. kommt auch sauber bei raus. die dateien sind allerdings nicht besser geworden.
ich werde das alles verwerfen müssen (leider).
neue frage: wie setzte ich einen raid5 nun richtig auf? habe scheinbar ein paar sachen "unschön" konfiguriert gehabt und auch kein LVM genutzt. Das raid ging auch auf das gesamte Gerät und keine Partition... was gibts da alles zu beachten, damit es "ordentlich" ist?
ich werde das alles verwerfen müssen (leider).
neue frage: wie setzte ich einen raid5 nun richtig auf? habe scheinbar ein paar sachen "unschön" konfiguriert gehabt und auch kein LVM genutzt. Das raid ging auch auf das gesamte Gerät und keine Partition... was gibts da alles zu beachten, damit es "ordentlich" ist?
Guck mal hier: http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
Ist zwar für die 10.3 geschrieben, sollte aber trotzdem weiterhelfen.
Ist zwar für die 10.3 geschrieben, sollte aber trotzdem weiterhelfen.