SoftUpdates/fsck considered harmful

Yar Tikhiy yar at
Fri Feb 27 04:09:56 PST 2004

On Sat, Feb 21, 2004 at 04:32:36PM -0500, Brian Fundakowski Feldman wrote:
> I lost some data which was important to me (thankfully, not lost completely, 
> as a fgrep on the hard disk was able to find a copy) because of a crash 
> while SoftUpdates had some data not yet flushed.  I simply had done this:
> 1. vi file
> 2. *edit edit edit, :wq*
> 3. ci file
> 4. co -l file
> That should have left me with several copies of it, but when the system 
> panicked, upon reboot fsck told me:
> Feb 19 21:34:46 green fsck: /dev/ad0s2e: UNREF FILE I=448021  OWNER=green MODE=100644
> Feb 19 21:34:46 green fsck: /dev/ad0s2e: SIZE=6298 MTIME=Feb 19 20:38 2004  (CLEARED)
> I'm certain this was the file I was editing.  SoftUpdates only guarantees 
> the disk is in a valid state, not that I won't lost files, but if fsck 
> hadn't decided that "UNREF" meant "the user did not intend this file to 
> exist any longer", I would have had a copy of it in /home/lost+found!  Can 
> there please be a less harmful behavior than simply not restoring unlinked 
> files just because they appear to be "UNREF"?

I'm afraid you demand from the filesystem logic what it isn't
supposed to provide.  In the case you described, having a remote
repository on a stable machine would be the solution.

On the one hand, using Softupdates indeed leads to probably "losing"
recently created files upon a system crash (which may be compensated
for by deleted files reappearing :-)  On the other hand, without
Softupdates one would have a close chance to end up with files that
existed but had inconsistent contents because of the crash preventing
some buffered data from being committed to stable storage.  Personally,
I see no point in trying to choose the lesser of the two evils when an
orthogonal path can be followed.  And Softupdates has the advantage
of keeping at least the filesystem metadata in a consistent state.

Now let's return to the fsck topic.  AFAIK "UNREF" means that the
reference count of an inode has dropped to zero because all links
from directories are gone, but the inode hasn't actually been freed
due to a system crash or malfunction.  This is different from the
case of a lost inode, which has a non-zero reference count but no
actual references from directories.  Therefore fsck will clear
UNREF'ed inodes, but reconnect lost ones to lost+found.  Please
correct me if I'm wrong.


More information about the freebsd-fs mailing list