From kris@obsecurity.org  Tue Mar 21 21:40:12 2006
Return-Path: <kris@obsecurity.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id C8BC116A400
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Mar 2006 21:40:12 +0000 (UTC)
	(envelope-from kris@obsecurity.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5BBE143D49
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Mar 2006 21:40:12 +0000 (GMT)
	(envelope-from kris@obsecurity.org)
Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196])
	by elvis.mu.org (Postfix) with ESMTP id 4686E1A4DD6
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Mar 2006 13:40:12 -0800 (PST)
Received: by obsecurity.dyndns.org (Postfix, from userid 1000)
	id C5B31514C3; Tue, 21 Mar 2006 16:40:11 -0500 (EST)
Message-Id: <20060321214011.C5B31514C3@obsecurity.dyndns.org>
Date: Tue, 21 Mar 2006 16:40:11 -0500 (EST)
From: Kris Kennaway <kris@FreeBSD.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: fsck incorrectly reports 'file system marked clean' when lost+found fills up
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         94810
>Category:       bin
>Synopsis:       fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-fs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 21 21:50:16 GMT 2006
>Closed-Date:    
>Last-Modified:  Fri Sep 24 20:50:59 UTC 2010
>Originator:     Kris Kennaway
>Release:        FreeBSD 6.1-PRERELEASE i386
>Organization:
FreeBSD
>Environment:
System: FreeBSD xor.obsecurity.org 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #18: Mon Mar 13 01:39:05 EST 2006 kkenn@xor.obsecurity.org:/mnt/src/sys/i386/compile/XOR i386

>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)

>How-To-Repeat:
>Fix:

The admin should be informed that due to lost+found filling up,
further action is required as above.

Even if the filesystem is being marked clean to facilitate the admin
mounting it, for the purposes of making additional space in lost+found
(this isn't strictly necessary since you can mount -f a dirty fs), the
admin should be informed that the filesystem damage is not yet
repaired.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Kris Kennaway <kris@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@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

From: Kris Kennaway <kris@obsecurity.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: Kris Kennaway <kris@freebsd.org>, FreeBSD-gnats-submit@freebsd.org,
	freebsd-bugs@freebsd.org
Subject: Re: bin/94810: fsck incorrectly reports 'file system marked clean' when lost+found fills up
Date: Tue, 21 Mar 2006 22:12:41 -0500

 --UlVJffcvxoiEqYs2
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Mar 22, 2006 at 02:10:03PM +1100, Bruce Evans wrote:
 > On Tue, 21 Mar 2006, Kris Kennaway wrote:
 >=20
 > >>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=3D871505  OWNER=3Droot MODE=3D40770
 > >SIZE=3D512 MTIME=3DJan  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)
 >=20
 > 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.
 
 I did run with fsck -y, and ended up having to iterate steps 1-3 a
 total of 7 times before the filesystem was completely clean.
 
 > 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.
 
 Yes.
 
 Kris
 
 --UlVJffcvxoiEqYs2
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2.2 (FreeBSD)
 
 iD8DBQFEIMCpWry0BWjoQKURAnmuAKDO7n5h09/DvT7nh81I5iirKl5ENwCaAheP
 jEhJMrDWv11I02B/FaLhSq8=
 =3maG
 -----END PGP SIGNATURE-----
 
 --UlVJffcvxoiEqYs2--
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: brucec 
Responsible-Changed-When: Fri Sep 24 20:50:39 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94810 
>Unformatted:
