Re: Re: Problem mit den e2fsprogs
>>> Wenn Du noch per debugfs an die Daten herankommst, kann man das
>>> eventuell skripten. Testdisk hast Du ja schon probiert. Mit welchem
>>> Erfolg?
>>
>> Mit debugfs komme ich definitiv noch an die Daten ran, wie es aussieht an so
>> gut wie alle. Mit testdisk komme ich nicht so richtig zurecht und weiß
n>icht,
>> was ich damit anstellen kann.
>
>Du musst bei testdisk eigentlich nur eine Partition bzw. ein Dateisystem
>auswählen und darüber laufen lassen.
Das "darüber laufen lassen" dauert aber bei dem Quick-Search-Schritt aufgrund
der Größe sehr lange. Vorher wird folgendes angezeigt:
Current partition structure:
Partition Start End Size in sectors
No FAT, NTFS, EXT2, JFS, Reiser, cramfs or XFS marker
1 P MS Data 34 5860543710 5860543677 [primary]
1 P MS Data 34 5860543710 5860543677 [primary]
Beim Quick Search werden dann schnell die folgenden Ergebnisse angezeigt:
Disk /dev/md0 - 4500 GB / 4191 GiB - CHS 1098851952 2 4
Analyse cylinder 745223469/1098851951: 67%
MS Data 2 4294967281 4294967280 [RAID5]
MS Data 32 5860543703 5860543672 [RAID]
MS Data 524320 5861067991 5860543672 [RAID]
Aber hier wird ewig nichts gefunden, so dass ich nach 2 Stunden die Suche
abgebrochen habe. Nun erscheint folgendes:
Disk /dev/md0 - 4500 GB / 4191 GiB - CHS 1098851952 2 4
Partition Start End Size in sectors
P MS Data 524320 5861067991 5860543672 [RAID]
Nach einem Druck auf "p" zum Anzeigen der Datein auf dieser Partition stürzt
testdisk mit undurchsichtiger Ausgabe ab.
>Vorzuziehen wäre aber
>wahrscheinlich die debugfs-Variante, wenn Dabei Dateinamen und -pfade
>erhalten bleiben. Hättest Du überhaupt den nötigen Platz für die Daten?
Nicht auf einem einzigem Datenträger. Für mich ist neben dem schieren Aufwand,
der sich durch ein Script wohl verringern lassen würde, auch der geringe freie
Zwischenspeicherplatz ein Problem, momentan sind nur rund 79GiB an freiem
Platz verfügbar. Ein Steckplatz für eine weitere Festplatte ist leider auch
nicht mehr frei. Ich würde daher auf andere Rechner übertragen müssen, wie
gesagt nach spätestens 79GiB. Ein weiteres Problem ist die Größe der Ordner,
die man, so weit ich das herausgefunden habe, nicht vorher sehen kann. So
würde ein rdump oder auch ein normaler dump in einigen Fällen fehlschlagen,
wenn die Festplatte bereits zu voll wäre.
Ärgerlich ist auch, dass man bei Ordnern mit Leerzeichen im Namen nur über
die inode-Nummer in ihn hineinwechseln/ihn dumpen kann. Wird ein Ordner beim
dumpen mit seiner inode-Nummer statt dem Namen angesprochen, so erhält der
gedumpte Ordner die inode-Nummer statt des Namens. Kann man das irgendwie
ändern?
>Eine Reparatur des Dateisystems halte ich nicht für unmöglich, aber da
>stecke ich nicht wirklich tief drin. Deine Ausgabe von debugfs macht
>auch nicht wirklich optimistisch, da sind einige unglaubwürdige Angaben
>drin (mount count, lifetime writes). Dass sich der fsck über ein
>fehlendes *externes* Journal beschwert, wundert mich auch. Sowas hast Du
>nicht, oder? (Wenn es so wäre, wüsstest Du das.)
Genau, kein externes Journal. Ich denke eher, dass fsck nach einem internen
sucht, keines findet, dann nach einem externen, dort auch keines findet und dann
einfach die letzte Fehlermeldung ausgibt. Oder irgendwo wurde eine Option auf
"externes Journal" gesetzt.
>Schick bitte noch die Ausgabe von debugfs mit verschiedenen Superblocks:
>
>debugfs -s <super-block> -b 4096 -show_super_stats /dev/md0p1
>Gültige Superblocks findest Du (hoffentlich noch) so:
>
># dumpe2fs /dev/md0p1 | grep -i super
Da wird bei allen Superblöcken das selbe wie vorher ausgegeben.
>Eigentlich würde ich erwarten, dass die weiter hinten liegenden
>Superblocks weiterhin gültige Daten enthalten, mit denen man weiter
>arbeiten kann. Post im Zweifel auch mal die Ausgabe eines fsck.ext4 -n
>mit einem anderen Superblock.
Auch hier wird bei allen Blöcken das selbe wie zuvor ausgegeben.
Reply to: