Hello,
I have a problem with a large (~ 450GB) UFS filesystem. It was uncleanly
unmounted, and /may/ (although this is not clear to me) have been partially
corrupted by an over-anxious plug and play RAID rebuilding. However some
semblance of data is still on the disk; in particular, it still contains a
valid boot block and running "strings" on a portion of the raw disk shows
portions of the data that used to be there. However, on running
"disklabel -p rz19" I get the following:
[snip]
8 partitions:
# size offset fstype [fsize bsize cpg] NOTE: values not exact
a: 131072 0 unused 0 0 # (Cyl. 0 - 7)
b: 262144 131072 unused 0 0 # (Cyl. 8 - 23)
c: 937754624 0 unused 0 0 # (Cyl. 0 - 57235)
d: 0 0 unused 0 0 # (Cyl. 0 - -1)
e: 0 0 unused 0 0 # (Cyl. 0 - -1)
f: 0 0 unused 0 0 # (Cyl. 0 - -1)
g: 468680704 393216 unused 0 0 # (Cyl. 24 - 28629)
h: 468680704 469073920 unused 0 0 # (Cyl. 28630 - 57235)
(reformatted to fit into 80 chars).
This is partially sane (slice c is the correct number of 512k blocks),
however previously slice a took up the whole disk and contained the UFS
filesystem in question.
Running fsck on slice a (or slice c) results in the following:
/sbin/ufs_fsck /dev/rz19a
** /dev/rrz19a
cannot alloc 111121921 bytes for statemap
This is reproducable on several machines; a DS10L, and some older
Alphastations.
I would be interested to hear of possible recovery methods for this data.
The catch might be that I have nowhere to put a 450GB image of the disk to
work on; however the amount of useful data on the disk probably doesn't
exceed 40 GB.
I imagine another possible fix might be to manually alter the slice table
(apologies for possibly incorrect terminology) but I'm not sure how to go
about this at all, nevermind safely (since disklabel -e would presumably end
up overwriting portions of data).
Thanks in advance for help.
--
Dominic Hargreaves || Astrophysics Deputy Systems Manager
Received on Wed May 07 2003 - 15:11:41 NZST