Karsten Kruse asserted

> :(  = may be broken, worst thing: even a manual fsck can't repair it
> :)  = should be ok, worst thing: some inclaimed inodes/blocks
> 
>               softdep, writebackcache on | no softdep, writebackcache on
> -----------------------------------------+------------------------------
> powerfailure            :(               |           :(
> reset                   :)               |           :(
> kernel panic            :)               |           :(
> 
> 
> The filesystem with softdep wins if writeback cache is on (wich is default).

offering the following as support:

> See http://www.mckusick.com/softdep/ (softdep) and
> http://sr5tech.com/write_back_cache_experiments.htm (writeback cache).

The first I had previously read, the second I had not.  The first does not
consider writeback caching at all; strictly speaking, wherever the paper says
a block is written to the disk, one needs to read that the block is placed
in the drive's writeback cache.

The second reference offered does not consider ffs or softdep at all, but
describes experiments conducted with ext3 and reiserfs that simply
demonstrate the undisputed fact that writeback caching can undermine the
integrity assurances of higher filesystem layers.  It will, of course,
also undermine ffs assurances (with or without softdep).

Offering these two references seems a bit like name-dropping.  They look
impressive but they don't support the claim.

It is important to remember that when you compare ffs-with-softdep to
ffs-without-softdep, you are not comparing to a filesystem that didn't
enforce metadata consistency; you are comparing to a system that strictly
enforced metadata consistency by ensuring that all metadata updates were
written (that is, placed in the disk's writeback cache) before the
associated kernel operation was allowed to return.  That is the baseline
that softdep has to be compared to.  You can find a good description of it
at /usr/share/doc/smm/03.fsck_ffs on your NetBSD box.

softdep improves performance by allowing some of those updates to be done
*after* the initiating operation returns.  It is safer than async because
at least it still tries to do those updates in a safe order (though a disk's
writeback cache will reorder the writes too).  But compared to plain ffs
without softdep and without async, softdep allows the disk state to lag
further behind the in-kernel state of the filesystem.  That means under
softdep at any given time there can be metadata updates completed in the
kernel that have not yet even been placed in the drive's writeback cache.

There *is* one detail where softdep does improve on the assurances in
baseline ffs.  It's on pages 3-4:

  Also, because the contents f the newly allocated disk location are
  unknown, rule #1 specifies an update dependency between the new block
  and the pointer to it.  Because enforcing this update dependency with
  synchronous writes can reduce data creation throughput by a factor of
  two, many implementations ignore it for regular data blocks.  This
  implementation decision reduces integrity and security, since newly
  allocated blocks generally contain previously deleted file data.  Soft
  updates allows all block allocations to be protected in this way with
  near-zero performance reduction.

That is one detail where softdep actually improves on security (though
because it applies only to regular data blocks, it is outside the concern of
metadata consistency and fsck).  However, in all other respects softdep is
passing metadata updates to the drive strictly no earlier than ffs would
have without it.  There is nothing intrinsic to softdep that makes it
safer with writeback disk caches.

Now, if you were prepared to present experimental data somehow showing that
softdep preserved integrity better on writeback caches in practice, it would
be interesting to look at, and speculate why (perhaps it is possible that the
overall reduction in traffic from softdep could have such a serendipitous
effect - or perhaps not).  When you cited the 'experiments' paper I thought
that's what it might be, until I looked and saw it did not pertain to ffs
or softdep.

Unless you have seen experimental results that genuinely suggest such a
benefit, I think it will be safer to regard softdep as a performance
enhancement, pure and simple.

-Chap