>Not quite right.  The buffer cache/VFS layer is modified to redirect synchronous
>data writes to the Prestoserve NVRAM and schedule async writes from the NVRAM.
>Hence NFS does not even know it's there.  This also helped other software which
>caused a lot of sync writes to happen (like directory updates on news servers).

I'm not sure Matt is quite correect either ;).

IIRC, the Ultrix PrestoServe was built on layering on _disk_ drivers,
with Prestoserve sandwiched below the filesystem but above the normal
disk drivers. PrestoServe looks like a regular disk to the filesystem.

Disk I/O got scheduled via a PrestoServe driver, which stored the
written data into NVRAM and scheduled an async write, as Matt
says. The read side checked NVRAM for pending writes, and then issued
reads to the real device for any misses in the NVRAM.

That accelerated database servers as well as NFS.

But (again IIRC) the design acutally chewed up an additional disk
major number for each disk present on the system. The static tables
for the different classes of disk driver (scsi, various MSCP, ...)
chewed up about 10 major numbers.

I dont recall if the I/O went through those extra numbers, or if the
Legato-derived code had an extra driver per Presto-able driver which
explicitly passed down the real, non-Presto driver entrypoint:

	sd_presto_open calling the Presto layer strategy 
	  with a pointer to sdopen as argument,
	sd_presto_strategy calling the Presto layer with a pointer
	to sdstragetgy as argument, etc.

All I remember from talking with Legato people is was that it was a
mess:). 

We could do something similar at the VFS layer, but it wouldn't help
database engines that access raw devices. To accelerate those, I think
you really want layering at the driver level. Ugh.

Followups should go to tech-kern as well.