Sebastian Schultz:
>
> Model: Linux Software RAID Array (md)
> Disk /dev/md0: 4501GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
>
> Number Start End Size File system Name Flags
> 1 17,4kB 3001GB 3001GB primary
Heiliger Bimbam, warum hast Du denn eine GPT auf dem RAID angelegt? Noch
dazu, wenn Du nur ein einzelnes Dateisystem mit der vollen Größe
benutzt? Entweder, man packt das FS direkt auf das md-Device, oder man
benutzt LVM.
Ich nehme auch stark an, dass Du Dir genau damit in den Fuß geschossen
hast. In Deiner History sieht man, dass Du selbst unsicher warst, ob das
FS nun auf /dev/md0 oder /dev/md0p1 liegt.
> resize2fs /dev/md0
Weißt Du noch, was hier passiert ist? Mit Pech ist an dieser Stelle
alles kaputt gegangen, weil md0 ja schon vergrößert wurde.
> resize2fs /dev/md0p1
Das dürfte nichts weiter getan haben, weil Du die Partition ja noch
nicht vergrößert hast.
> Wie schlimm war das e2fsck /dev/md0, was wohl das gewesen sein müsste, wo ich
> die vielen Fehler hatte, die ich mit y bestätigte?
Entweder damit, oder mit dem vorigen resize2fs /dev/md0 hast Du Dir das
Dateisystem zerschossen, das, wie ich annehme, eigentlich auf /dev/md0p1
liegt/lag. *Eigentlich* sollte dabei gar nichts passieren, aber
eventuell war da ein beteiligtes Programm zu schlau. Dass die GPT kaputt
ist, weist aber auch darauf hin, dass genau das passiert ist.
Es wäre auch überhaupt kein Problem gewesen das resize2fs auf das
Dateisystem loszulassen, bevor die Partition vergrößert wurde. Da wäre
halt einfach nichts bei rausgekommen.
Wenn Du noch per debugfs an die Daten herankommst, kann man das
eventuell skripten. Testdisk hast Du ja schon probiert. Mit welchem
Erfolg?
J.
--
Fashion is more important to me than war, famine, disease or art.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature