From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 27 07:52:42 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 42E8416A4CE for ; Tue, 27 Jul 2004 07:52:42 +0000 (GMT) Received: from mail016.syd.optusnet.com.au (mail016.syd.optusnet.com.au [211.29.132.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B54B43D5C for ; Tue, 27 Jul 2004 07:52:41 +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]) i6R7qQG16388; Tue, 27 Jul 2004 17:52:28 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i6R7qQVd019716; Tue, 27 Jul 2004 17:52:26 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i6R7qPqq019715; Tue, 27 Jul 2004 17:52:25 +1000 (EST) (envelope-from pjeremy) Date: Tue, 27 Jul 2004 17:52:25 +1000 From: Peter Jeremy To: Charles Sprickman Message-ID: <20040727075225.GL3001@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> <20040722075723.GE3001@cirb503493.alcatel.com.au> <20040726142446.P28049@toad.nat.fasttrackmonkey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040726142446.P28049@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: Tue, 27 Jul 2004 07:52:42 -0000 On Mon, 2004-Jul-26 14:30:08 -0400, Charles Sprickman wrote: >I did get confirmation from Adaptec that it does go from the outside >sectors in. In which case one of the first things to be over-written would have been the first superblock and fsck should complain and stop immediately if this is invalid. >I ended up using sysutils/ffsrecov to grab the alternate superblocks. Maybe that was the tool I was thinking of. >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? fsck will grow the lost+found directory if necessary but it can only grow it to the limit of the direct blocks (12 filesystem blocks). The only way to pre-grow the lost+found directory would be to mount the filesystem read/write, create a large number of (preferably large) filenames and then delete them[1]. I'm not sure if the fsck code can understand indirect blocks in the lost+found directory so I don't know if this would work. It also relies on the filesystem to be sane enough for normal block allocation to work. One option might be to force a read/write mount, rename lost+found, umount the filesystem and redo the fsck until it fills the new lost+found. Renaming a directory entry is fairly safe, especially if you don't change the entry size. Alternatively, do this with fsdb - which is definitely safe. [1] Directories are only shrunk when an entry is created, not when one is deleted. -- Peter Jeremy