Subject: Re: Crash-resilience of FFS (w/softdeps)
To: None <netbsd-users@netbsd.org>
From: David Laight <David.Laight@btinternet.com>
List: netbsd-users
Date: 11/29/2001 10:18:07
> > I'm a NetBSD newbie running NetBSD-1.5.2 on an Alpha with /usr mounted
> > using softdeps.  I'm curious to know how resilient the FFS is, particularly
> > when using softdeps, on unclean shutdowns.  I come from a heavy Linux (and
> > therefore EXT2) background.
> 
> The FFS takes care to correctly order all metadata operations, as well as to
> ensure that all metadata operations precede operations on the data to which
> they refer, so that the filesystem may be guaranteed to be recoverable after
> a crash.  The last N seconds of _file data_ may not be recoverable, where
> N is the syncer interval, but the filesystem metadata will be.  N is usually
> 30.

As a software developer, the usual problem is that, after a crash (or
untidy shutdown) the file you just finished editing has zero size!
(especially when you are testing loadable device drivers....)

Fsck typically reports a mismatch in the file size, decides zero is
correct then throws the unreferences zero sized file away.

I believe what actually happens is that someone (a standards body) decided
that truncating a file required that the inode be written out to disk,
but closing a file doesn't require the current size to be written out.
(This was about the point that the 'inode modification time' became
useless because the file size and last accessed date are held in the
inode...)
When an editor rewrites a file it gets truncated first....
I strongly suspect that, since the file has sectors allocated to it, they
might contain (most of) the file.  Clearly the file could be corrupt -
but in many cases much of the data might be recoverable...

I can't see that FFS actually helps in these cases.....
(but it may well help database code)

    David