From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 22 03:10:14 2006 Return-Path: X-Original-To: freebsd-bugs@freebsd.org Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C098916A400; Wed, 22 Mar 2006 03:10:14 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE2A743D53; Wed, 22 Mar 2006 03:10:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (Postfix) with ESMTP id E8BF58DEEA; Wed, 22 Mar 2006 14:10:10 +1100 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2M3A3DB030016; Wed, 22 Mar 2006 14:10:04 +1100 Date: Wed, 22 Mar 2006 14:10:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Kris Kennaway In-Reply-To: <20060321214011.C5B31514C3@obsecurity.dyndns.org> Message-ID: <20060322134531.P82503@epsplex.bde.org> References: <20060321214011.C5B31514C3@obsecurity.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/94810: fsck incorrectly reports 'file system marked clean' when lost+found fills up X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 03:10:14 -0000 On Tue, 21 Mar 2006, Kris Kennaway wrote: >> Description: > > In cases of severe filesystem damage, fsck may fill up lost+found: > > [...] > SORRY. NO SPACE IN lost+found DIRECTORY > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > UNREF DIR I=871505 OWNER=root MODE=40770 > SIZE=512 MTIME=Jan 1 09:59 1970 > RECONNECT? yes > > SORRY. NO SPACE IN lost+found DIRECTORY > UNEXPECTED SOFT UPDATE INCONSISTENCY > [...] > > However, when fsck eventually completes it reports > > ***** FILE SYSTEM MARKED CLEAN ***** > ***** FILE SYSTEM WAS MODIFIED ***** > > In fact, all of the damage was not repaired since the extra files > could not be reconnected to lost+found, so it is necessary to: > > 1) mount and clean out lost+found or move it aside > > 2) unmount and rerun fsck to continue recovering lost files. > > 3) Repeat until all files have been recovered (may take multiple > iterations) Steps 2 and 3 seemed to be unnecessary when I ran fsck with -y. Then seemed to just delete everything that couldn't be reconnected to lost+found, and fsck's claim to have cleaned the file system seemed to be correct because the deletions worked. Another problem with fsck -y is that you have to use it too much because the interactive interface for answering y/n doesn't scale to large file systems with relatively small but absolutely large damage. fsck -y should only be used for disposable file systems, but even then you might want to try to preserve 2 files without interactively answering y/n up to N*2^32 times for the ones you don't care about. Bruce