From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 07:57:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDA5316A4CE for ; Thu, 22 Jul 2004 07:57:35 +0000 (GMT) Received: from mail018.syd.optusnet.com.au (mail018.syd.optusnet.com.au [211.29.132.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC9643D53 for ; Thu, 22 Jul 2004 07:57:32 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i6M7vPF04046; Thu, 22 Jul 2004 17:57:26 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i6M7vOVd009300; Thu, 22 Jul 2004 17:57:24 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i6M7vNTm009299; Thu, 22 Jul 2004 17:57:23 +1000 (EST) (envelope-from pjeremy) Date: Thu, 22 Jul 2004 17:57:23 +1000 From: Peter Jeremy To: Charles Sprickman Message-ID: <20040722075723.GE3001@cirb503493.alcatel.com.au> References: <20040719191408.V28049@toad.nat.fasttrackmonkey.com> <20040720021432.O28049@toad.nat.fasttrackmonkey.com> <20040720092848.GD3001@cirb503493.alcatel.com.au> <20040720135157.Q28049@toad.nat.fasttrackmonkey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040720135157.Q28049@toad.nat.fasttrackmonkey.com> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: disk recovery help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2004 07:57:36 -0000 On Tue, 2004-Jul-20 14:01:06 -0400, Charles Sprickman wrote: >On Tue, 20 Jul 2004, Peter Jeremy wrote: > >> It's difficult to see how a sanely written RAID utility could totally >> screw up an array in a short time Upon reflection, one obvious way is to change the array layout. I don't know enough about your configuration and Adaptec's raidutil to know if this is likely. >command does, but they are fairly certain that it writes it's config at >the end of the disk, then zeros it from the outside in. Which puts an upper limit on the amount of damage done. The only difficulty with this is that (ISTR) your filesystem begins at the beginning of the array so the primary superblock should be the first thing over-written - and fsck would whinge loudly about that. >grabbed the dd "image" before that. An fsck on the problem partition ran >for 12 hours and I don't know how far along it was. Ctrl-T (aka SIGINFO) is your friend - fsck will tell you how far through its current phase it is. > I looked at scan_ffs >just now, and it looks like it works on the whole disk trying to find the >label. Since I only have one partition, there's no label. scan_ffs searches the disk (or file) looking for UFS superblocks. The most common reason for needing this is to re-generate your partition tables. I was hoping it would also locate all the superblocks - which would let you verify that the structure looked reasonably sane. You might also try fsdb(8) - though I think it relies on the primary superblock being sane. Good luck. -- Peter Jeremy