Looking for help to reconstruct a corrupted UFS2 filesystem
Eric Anderson
anderson at freebsd.org
Fri Feb 1 14:31:31 UTC 2008
Matt Emmerton wrote:
>> 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.
You probably have a corrupt cylinder group, which is a common problem
when something like this corrupts the cg blocks badly. You might be
able to go in with fsdb and find the badness, or (eek!) a hex editor to
the right spot on disk and change the values. I would highly recommend
dd'ing the disk to a file on another disk prior to doing either of those
things, and work on the image file.
Eric
More information about the freebsd-fs
mailing list