From owner-freebsd-fs@FreeBSD.ORG Sun Jan 20 22:46:07 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364C016A498 for ; Sun, 20 Jan 2008 22:46:07 +0000 (UTC) (envelope-from matt@gsicomp.on.ca) Received: from daisy2.compar.com (mail1.compar.com [216.208.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 04E2813C4D5 for ; Sun, 20 Jan 2008 22:46:06 +0000 (UTC) (envelope-from matt@gsicomp.on.ca) Received: from localhost (localhost.compar.com [127.0.0.1]) by daisy2.compar.com (Postfix) with ESMTP id 0F8DF13C46D; Sun, 20 Jan 2008 17:46:06 -0500 (EST) X-Virus-Scanned: amavisd-new at compar.com Received: from unknown by localhost (amavisd-new, unix socket) id tPOyDIf9EpbZ; Sun, 20 Jan 2008 17:46:03 -0500 (EST) Received: from hermes (CPE00062566c7bb-CM001ac3584898.cpe.net.cable.rogers.com [99.236.43.116]) by daisy2.compar.com (Postfix) with SMTP id 0BD7F13C424; Sun, 20 Jan 2008 17:46:02 -0500 (EST) Message-ID: <002201c85bb6$3d2a7fb0$1200a8c0@hermes> From: "Matt Emmerton" To: References: <000801c85b94$f3a58ea0$1200a8c0@hermes> <1200856930.9818.2.camel@jill.exit.com> Date: Sun, 20 Jan 2008 17:46:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-fs@freebsd.org Subject: Re: Looking for help to reconstruct a corrupted UFS2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2008 22:46:07 -0000 > 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 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