This is a discussion on Re: Looking for help to reconstruct a corrupted UFS2 filesystem - FreeBSD ; 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 ...
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
>>> 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
>>> 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
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.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"