Subject: Re: wd, disk write cache, sync cache, and softdep.
To: Charles M. Hannum <>
From: Daniel Carosone <>
List: tech-kern
Date: 12/17/2004 10:50:43
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 16, 2004 at 11:30:11PM +0000, Charles M. Hannum wrote:
> On Thursday 16 December 2004 23:23, Daniel Carosone wrote:
> > Finally, it's about getting the most out of cheap hardware - not just
> > the most performance but the most reliability as well.
> I have to conclude from this that you actually don't understand the real=
> problems at all.

Rather, I'm trying to address just one component of it.

> * You can lose critical file system data (say, the root inode) just by tu=
> off the power in the middle of a write.  Fixing this properly really=20
> *requires* journaling.  As Jason mentioned, your journaling system can ta=
> care of the write ordering during flushing (and without much performance=
> loss).

It doesn't specifically require journalling, though that's certainly
one way to address it.  Other ways include never overwriting data
in-place, such as it seems Solaris' new zfs claims to do, or in a
manner similar to postgresql's MVCC.  I've also seen journalled block
devices, either for the fss(4)-style case, or as a quicker hack than
rewriting the filesystem, though I'm not proposing one of those as a
good solution.

There's no question from me that NetBSD could also use better
filesystems, for all sorts of reasons.

> * There are other reliability problems, some of which were mentioned in r=
> (albeit terse) PRs, that are *much* bigger than the risk from the drive's=
> write cache.


> You're shooting at the wrong target.

That depends on your definition of 'wrong'.  I'm shooting at the one I
can hit from where I'm standing, and hoping my comrades on the next
hill are shooting at stuff I can't.  Fire away.


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)