Subject: Re: Crash-resilience of FFS (w/softdeps)
To: B. James Phillippe <bryanxms@ecst.csuchico.edu>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: netbsd-users
Date: 11/28/2001 20:02:42
On Wed, Nov 28, 2001 at 03:00:06PM -0800, B. James Phillippe wrote:
> Hello,
> 
> 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.

With softdeps running, you've got *almost* the same guarantee.  With
softdeps, you have the guarantee that you will get a consistent snapshot
of the filesystem as it was at some particular point in time before the
crash.  So you don't know, as you did without softdeps, that, for example,
if you did an atomic operation such as a rename of a lock file, the lock
file will actually be there; but you do know that the directory it was
in won't be trashed (which is not the case with Linux) and you do know
that ordering dependencies between that atomic operation and future
atomic operations will have been preserved, so if you are depending on
atomic operations to control, say, some database-like process (e.g.
writing mail spool files in batches, gathering data from a transaction
system, etc.) you can safely start back up where you appear to have left
off.

It's amusing to note that our ext2fs implementation gives you the 
traditional FFS guarantee about metadata, *unlike the Linux implementation*,
so you can actually use it with more confidence than you can use the native
ext2fs in Linux.  The downside is that it's a bit slower, but that's because
it actually does the right thing if the system crashes, instead of potentially
eating your filesystem itself.

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron