From owner-freebsd-fs@FreeBSD.ORG Fri Feb 1 14:31:31 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 9FE1116A417 for ; Fri, 1 Feb 2008 14:31:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC8D13C447 for ; Fri, 1 Feb 2008 14:31:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.tenantsolutions.net [209.163.168.124] (may be forged)) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id m11EVL7X025088; Fri, 1 Feb 2008 08:31:22 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <47A32D39.5090105@freebsd.org> Date: Fri, 01 Feb 2008 08:31:21 -0600 From: Eric Anderson User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Matt Emmerton References: <000801c85b94$f3a58ea0$1200a8c0@hermes> <1200856930.9818.2.camel@jill.exit.com> <002201c85bb6$3d2a7fb0$1200a8c0@hermes> In-Reply-To: <002201c85bb6$3d2a7fb0$1200a8c0@hermes> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com 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: Fri, 01 Feb 2008 14:31:31 -0000 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 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