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