Date: Fri, 01 Feb 2008 08:31:21 -0600 From: Eric Anderson <anderson@freebsd.org> To: Matt Emmerton <matt@gsicomp.on.ca> Cc: freebsd-fs@freebsd.org Subject: Re: Looking for help to reconstruct a corrupted UFS2 filesystem Message-ID: <47A32D39.5090105@freebsd.org> In-Reply-To: <002201c85bb6$3d2a7fb0$1200a8c0@hermes> References: <000801c85b94$f3a58ea0$1200a8c0@hermes> <1200856930.9818.2.camel@jill.exit.com> <002201c85bb6$3d2a7fb0$1200a8c0@hermes>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A32D39.5090105>