Subject: Re: Prestoserve module
To: Christopher Tribo <t1345@hopi.dtcc.edu>
From: Matt Thomas <matt@3am-software.com>
List: port-pmax
Date: 04/01/2003 13:29:31
At 12:55 PM 4/1/2003, Christopher Tribo wrote:
>On Wed, 2 Apr 2003, Collin Baillie wrote:
>
> > Just a quick question:
> >
> > Is the unsupported state of the prestoserve modules in the pmax boxen 
> due to
> > lack of interest or lack or hardware in a developer's possession?
>
>         Lack of any real gain and lack of documentation. The way I
>understand it Legato owns the code and documentation from the Ultrix days.
>Maybe users on the VAX port would have some further insights.
>
>         Working it into NFS and/or CODA would be a challenge. Maybe
>working it in as some type of low priority kernel asigned buffer area and
>have NFS use it would work, but that's a lot of kernel machinery to muck
>with.

That's not how it works.  It works *below* the filesystem inside the
buffer cache.  When a filesystem needs to do a synchronous write to the
disk (which is usually metadata), the buffer cache writes the 
data/location/disk
to the NVRAM on the prestoserve, schedules a new async I/O to do the write,
and marks the current I/O as done.  So the buffer cache sees it as completing
really fast.  Now when the buffer cache does a read, it check the NVRAM first
before going to disk since the data may be in the NVRAM and not on the disk 
yet.

Also, when initializing the buffer cache (actually, when opening a disk 
partition
any pending write in the NVRAM are written to the disk before allowing the open
to finish.  This is needed so that fsck (since it bypasses the buffer 
cache) will
always get a true image of the filesystem.

The above techniques still have merit even today.  I've been talking to a 
friend
which does hardware design about designing a PCI board that could have 
1-2GB of
NVRAM (which you can DMA to/from system memory to the NVRAM).  Imagine a board
that could "act" as your disk with full PCI bandwidth I/O rates. :)


-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message