Hello,

On Thu, 16 Dec 2004 07:13:42 +0000, Daniel Carosone wrote:

> I've written before about drive write cache issues, and about the mess
> that can be made of a filesystem by the reordering or non-completion
> of acknowledged writes that might happen with write cache on when
> power fails.  This gets much worse, obviously, with softdep, which
> depends even more heavily on ordering assumptions.

Thanks for your analysis. I thought I'm alone in thinking that having
softdeps carefully ordering writes and the disk carefully destroying that
ordering, especially when the write cache is on by default, is a serious
bug in NetBSD.

> I've come to the general conclusion that if you're going to use
> softdep, you need to disable write cache - and if you're going to
> disable write cache, you pretty much need softdep or the performance
> impact is truly horrendous.  Softdep will save you an awful lot of
> sync rewrites updating the same inode or directory over and over.

If you enable write cache and disable softeps, the preformance isn't
horrendous because the disk doesn't do what the filesystem expects, so it
is IMHO better to just use async mounting, which gives you the same
guarantees (none) with even better speed.

> The idea is for the wd driver to issue commands to the disk, with
> write-cache on, but to collect the ~immediate completion events in a
> separate completion queue. The driver periodically (on a number of
> conditions, see below) issues a sync cache command, and only when that
> returns does it biodone() the previous requests in the completion queue,

I think this is a fine idea.

> Conditions for issuing a synccache in this fashion might include:

What about adding the condition that the total size of all unsynced write
requests is greater than the size of on-disk cache?

Bye	Pavel