From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 26 18:31:57 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 8E10316A4CE for ; Mon, 26 Jul 2004 18:31:57 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B40CA43D70 for ; Mon, 26 Jul 2004 18:31:54 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 2264 invoked by uid 2003); 26 Jul 2004 18:30:28 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.04492 secs); 26 Jul 2004 18:30:28 -0000 Received: from unknown (HELO toad.nat.fasttrackmonkey.com) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jul 2004 18:30:26 -0000 Date: Mon, 26 Jul 2004 14:30:08 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@toad.nat.fasttrackmonkey.com To: Peter Jeremy In-Reply-To: <20040722075723.GE3001@cirb503493.alcatel.com.au> Message-ID: <20040726142446.P28049@toad.nat.fasttrackmonkey.com> 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> <20040722075723.GE3001@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 26 Jul 2004 18:31:57 -0000 On Thu, 22 Jul 2004, Peter Jeremy wrote: > >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. I did get confirmation from Adaptec that it does go from the outside sectors in. > >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. Ah. Hence the reference to stty in the fsck manpage. Thanks! > 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. I ended up using sysutils/ffsrecov to grab the alternate superblocks. I have a reasonably OK fsck'd filesystem mounted now. I have another copy to work on, and my question there is this: When you run fsck it creates a "lost+found" directory to put files that are unreferenced anywhere (I think that's the terminology). At some point during the fsck, it starts spitting errors about there not being enough space in "lost+found". Is there any way to remedy that problem? Is there some way to "grow" the filesystem *before* fsck-ing it? The only bit about this in the fsck manpage is the following: "If the lost+found directory does not exist, it is created. If there is insufficient space its size is increased." Thanks to everyone for your help so far. This has been a good learning experience. Charles > Good luck. > > -- > Peter Jeremy >