Looking for help to reconstruct a corrupted UFS2 filesystem

[Matt Emmerton]

> On Sun, 2008-01-20 at 13:47 -0500, Matt Emmerton wrote:
>> What are my options at this point?  Since all the superblocks are 
>> identical,
>> fsck always behaves the same.  I suspect that one of the key blocks that 
>> the
>> superblock points to is corrupted.  Is any of this data replicated on 
>> disk?
>> Can I troll the disk looking for intermediate blocks and easily chain
>> together portions of directory trees?
>
> This kind of thing is why I put ports/sysutils/ffs2recov together.  You
> won't be able to recover everything but you should be able to get a lot
> of it back.

Thanks Frank.  I'm playing around with this tool now.  Something must be 
really hosed since I'm getting a lot of segfaults.

For example, ffs2recov -s /dev/ad1s1 segfaults after finding 3 superblocks, 
and these superblocks aren't close to anything that newfs -N dumps out 
(except the one at offset 160).  It also attempts to read blk 
18445195961337644512, which is clearly wrong.  (I'm 99% sure that I used the 
newfs defaults when I created this filesystem, so why would ffs2recov be 
looking for superblocks in different locations?)

ffs2rrecov -p also segfaults after dumping part of cg 3, and ffs2recov -d 
segfaults after hitting inode 8331.

ffs2recov -a and ffs2recov -r <name> do a lot of complaining regarding 
failure to allocate large amount (or negative) memory.

I'm guessing that it's starting off with bad data, and that's not helping. 
I'm doing some brute force work with ffs2recov -i to sniff out good inodes 
and will start from there.

Regards,
--
Matt