bin/94810: fsck incorrectly reports 'file system marked clean' when lost+found fills up

[Bruce Evans]

The following reply was made to PR bin/94810; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Kris Kennaway <kris at freebsd.org>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: bin/94810: fsck incorrectly reports 'file system marked clean'
 when lost+found fills up
Date: Wed, 22 Mar 2006 14:10:03 +1100 (EST)

 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