UFS2 superblock backups

[Wasp]

Wurde gestern von dem hier auf meiner /var Partition überrascht:

.....
(ada5:ata5:0:0:0): READ_DMA. ACB: c8 00 09 45 e7 40 00 00 00 00 01 00
(ada5:ata5:0:0:0): CAM status: ATA Status Error
(ada5:ata5:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC )
(ada5:ata5:0:0:0): RES: 51 40 09 45 e7 00 00 00 00 00 00
(ada5:ata5:0:0:0): Error 5, Retries exhausted

Leider kann ich das Problem nicht so leicht lösen/umgehen wie ich naiverweise annahmt. Was ich bereits versucht habe:

• `fsck -y /var` natürlich, welcher aber nur wieder gleichen Fehler ausgibt.
• `dd if=/dev/ada5p4 of=/dev/ada5p10 bs=4M conv=noerror,notrunc` und dann noch einmal fsck(8), aber interessanter Weise habe ich dort das gleiche Problem.
• Fand auf https://forums.freebsd.org/threads/16984/ jemand der ähnliches Problem hat/hatte und habe dann auch `newfs -N /dev/ada5p10` und dann `fsck_ffs -b 7693632 /dev/ada5p10` ausgeführt, aber wie im verlinkten Beitrag bei mir gleiches Problem: "Alternate super block location: 192 ** /dev/ada5p10 7693632 is not a file system superblock", obwohl es mir zuvor von newfs(8) als super-block backup ausgegeben wurde.

Eigentlich scheinen bei mir nur 2 Blöcke(?) defekt zu sein, hatte gehofft, kann die einfach "wegschmeissen" um dann wenigstens auf die restlichen Daten zugreifen zu können.

Andere Idee, daß das SATA-Kabel defekt ist, ist anscheinend nicht zutreffend -- bereits gegen ein erwiesenermaßen intaktes ausgetauscht.

Jemand eine Idee, wie ich meine Daten von der Partition noch retten kann? Kann doch nicht an zwei blöden Blöcken scheitern...

Auf hilfreiche Hinweise hofft,
Wasp

 

[Wasp]

Update:
Hatte hinten begonnen die Superblöcke auszuprobieren. Superblock 192 wird zumindest erkannt, aber nach endlosem "y" eingeben nur `fsck_ffs: bad state 0 for inode I=160512` und erneutes `fsck -y /dev/ada5p10` sagt dann immer noch

BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE ioctl (GCINFO): Inappropriate ioctl for device
fsck_ffs: /dev/ada5p10: can't read disk label

Falls die Ausgabe von fsck(8) jemanden irgendwie weiterhilft, hier noch eine gekürzte Übersicht, wobei effektiv nur zwei Daten `empty/` und `cron/` betroffen zu sein scheinen:

Partially truncated inode I=80273
Salvage? [yn] y
Incorrect block count I=80273 (3712 shoud be 1472)
Corrrect? [yn] y
Cylinder group 2: bad magic number.
Rebuild cylinder group? [yn] y
Unknown file type I=160780
Clear? [yn] y
(...)
Partially allocated inode I=160783
Clear? [yn] y
Cylinder group 2: found 512 valid indoes
Cylinder group 3: bad magic number
Rebuild cylinder group? [yn] y
(...)
** Phase 2 - Check Pathnames
Unallocated I=401280  OWNER=root MODE=0
SIZE=0 MTIME=Jan   1 01:00 1970
NAME=/cron

Remove? yes

Unallocated I=240768  OWNER=39828786 MODE=57631
SIZE=2968156238444326912 MTIME=Jan   1 01:00 1970
NAME=/empty

Remove? yes

fsck_ffs: bad state 0 for indoe I=160512

Leider bekomme ich das Dateisystem nicht "clean". Weiß da jemand Rat?

 

[metro]

Es kann sein, dass das Dateisystem (nach fsck_ffs -b ***) am Ende schon wieder mountbar ist, obwohl da noch jede Menge Fehlermeldungen erscheinen.
Ich habe in ähnlicher Situation das kaputte Dateisystem mit dem sehr effektiven Tool recoverdisk(1) geklont, und dann an dem Klon die entsprechenden fsck_ffs -Läufe gestartet.
Wenn du das machst, wird recoverdisk(1) am Ende (je nach Rechenpower u.U. LANGER Zeit) auf den unlesbaren Blöcken loopen. Es zeigt dann 100% done und will per Strg ^C gestoppt werden.
newfs -N gibt ja netterweise eine Vielzahl von alternativen Superblocks aus, also probier einfach mal einen anderen.
fsck_ffs(8) hat übrigens, wie fsck(8) den Schalter '-y' , damit erspart man sich erfolgreich stundenlanges Tippen von 'y', also fsck_ffs -y -b *** /pfad/dateisystem
Du wirst vielleicht nicht alle Daten wieder lesbar herstellen können, aber zumindest die nicht zerstörten.
hth

P.S.: Eventuell die defekte Platte erneuern ?!?

 

[Wasp]

Danke für den Hinweis mit dem recoverdisk(1), kannte ich noch gar nicht. Ging glaube ich gut mit dem kopieren, leider scheint es aber ein Problem mit dem onboard SATA-Controller zu sein. bekomme ähnliche Fehlermeldungen hin und wieder nun auch von anderen Platten am SATA-Controller.
Werde sie wohl mal ausbauen müssen, und gucken ob das Problem an anderem Rechner bestehen bleibt.

 

[Fusselbär]

Bin mir nicht sicher, ob es noch relevant sein mag, aber mittlerweile gibt es einen Eintrag bezüglich der Superblocks in UPDATING:

20170822:
Since the switch to GPT disk labels, fsck for UFS/FFS has been
unable to automatically find alternate superblocks. As of r322806,
the information needed to find alternate superblocks has been
moved to the end of the area reserved for the boot block.
Filesystems created with a newfs of this vintage or later
will create the recovery information. If you have a filesystem
created prior to this change and wish to have a recovery block
created for your filesystem, you can do so by running fsck in
forground mode (i.e., do not use the -p or -y options). As it
starts, fsck will ask ``SAVE DATA TO FIND ALTERNATE SUPERBLOCKS''
to which you should answer yes.

Dort gibt es mehr dazu:
http://www.secnetix.de/olli/FreeBSD/svnews/index.py?r=322806
Und hier lässt sich die Diskussion dazu nachlesen:
https://reviews.freebsd.org/D11589