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