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.


More information about the freebsd-fs mailing list