Summary: | fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up | ||
---|---|---|---|
Product: | Base System | Reporter: | Kris Kennaway <kris> |
Component: | bin | Assignee: | freebsd-fs (Nobody) <fs> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | grahamperrin, lwhsu |
Priority: | Normal | ||
Version: | 6.1-PRERELEASE | ||
Hardware: | Any | ||
OS: | Any |
Description
Kris Kennaway
2006-03-21 21:50:16 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 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 Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s). 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 |