Bug 94810 - fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up
Summary: fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 6.1-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-21 21:50 UTC by Kris Kennaway
Modified: 2021-07-21 17:19 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kris Kennaway freebsd_committer 2006-03-21 21:50:16 UTC
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)

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.
Comment 1 Bruce Evans 2006-03-22 03:10:03 UTC
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
Comment 2 Kris Kennaway 2006-03-22 03:12:41 UTC
On Wed, Mar 22, 2006 at 02:10:03PM +1100, Bruce Evans wrote:
> 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.


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
Comment 3 Bruce Cran freebsd_committer 2010-09-24 21:50:39 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:00 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped