We may need to rethink caching a bit. Right now, the two levels of it that
we've been discussing are:

1. in the main RAM of the of the system, some number of NetBSD kernel
buffers holding disk blocks are kept around, to avoid hitting the disk for
that information more than once in some period of time, subject to
available memory restrictions.

2. in the HDA electronics of various disk drives.

We currently have some per-filesystem options for being more aggressive
about caching, and how often we force bits to oxide for reliability, e.g.
B_ASYNC.

It strikes me that we need a SCSI (and possible EIDE) tool for playing with
the options available in the HDA electronics, and some documentation that
lays out the options and risks for the person configuring a NetBSD system.
There is a program I recall, called "scsitool" (or somesuch) from U of
Toronto, that might be a good place to start.

The tradeoff, roughly, is performance against robustness in the face of
failure (failure being, generally, a power failure, or a NetBSD panic).

Complicating matters somewhat is that we usually have more than one
filesystem per disk - if you have different policies for the filesystems on
a single disk, generally the most restrictive one should control what the
HDA electronics get told to do. Best performance is going to be gotten from
laying out your filesystem according to some interesting matrix of
reliability requirements, frequency of data access, and how many disks you
have to play with. Messy.

The documentation of this issue is a bare minimum requirement.

After that, some tools to help do system layout would be nice. Do we have
any recent filesystem utilization statistics to drive that with?

	thinking out loud again,

	Erik <fair@clock.org>