> >> > > Then for the real test start over and do it all again, but this time
> >> > > after "systat bufcache" shows that most of available RAM is used up
> >> > > for metadata an file data, pull the power plugs.  Then try to clean
> >> > > up the mess.
> >> >
> >> > What mess?  My understanding is that with soft updates, the only
> >> > thing that can possibly happen is that disk space can be lost.
> >> > The background fsck is for reclaiming this lost space.
> >>
> >> That's both the idea and the promise. For better or worse, that has
> >> not=20
> >> been the experience of a number of users.
> >
> > Did these users have their disk's write caches set to write-through
> > mode rather than write-back mode?
> 
> For one yes

So no one believes Usenix papers by respected authors, but we have one
report from an unknown user with unknown hardware that softdep allegedly
caused lossage and therefore no one trusts softdeps?

> > NetBSD doesn't do this by default, you have to add code to /etc/rc.local.
> 
> If we get a journalling implementation that's something it can take care
> of, whether it's PATA (flush the cache) or SCSI, where it can force access
> to the disc.

Flushing the entire cache is unnecessary and will kill performance.
We only need to force the order for the metadata, for everything else
we want to allow the disk to order the writes for the best performance.
The way to do that is queuing.  IIRC *BSD has queuing for SCSI, but
I haven't been able to find support for SATA's NCQ.  Where is the NCQ
support?