Subject: NVRAM for NFS
To: None <current-users@netbsd.org>
From: Aaron J. Grier <agrier@poofy.goof.com>
List: current-users
Date: 12/27/1999 13:17:24
(this started on port-i386, but it seemed more appropriate to followup
to current-users since building your own NetApp could be accomplished on
multiple platforms...)

On Mon, Dec 27, 1999 at 11:27:20AM -0800, jonathan@dsg.stanford.edu wrote:

> The mid-80s advice used to be, get an NVRAM board so the servers can
> log writes to NVRAM and reply, rather than waiting till NFS write
> requests go all the way out to disk before replying. I have no idea if
> the NetApps do that, but if they do, then write latency will be hard
> to beat.

This is _exactly_ what they do.  NetApps run (ran) RAID4 [1] and since
they have NVRAM, can defer writes until they have a full stripe, thus
avoiding the RAID4 "bang on the single parity disk" problem.  Couple
that with a log-based filesystem, and they can suck down quite a bit of
NFS traffic.  NetBSD already has RAIDFrame and LFS.  :)

The thing that seems to be missing is NVRAM hardware support.  Last I
asked about this on port-pmax two years ago, I was told that the NFS
code would have to be significantly restructured to support DEC-style
PrestoServe hardware.  So I assume the i386-specific advice offered by
Jonathan is referring to NVRAM directly on the controller card?  Or are
PrestoServe cards supported under -current?  I'm sure sun (and other
platforms) have non-controller-connected NVRAM hardware...  this seems
like something we could leverage across multiple platforms.

[1] I'm pretty sure they're doing something a little more sophisticated
    now, but originally it was RAID4.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofy.goof.com
  "Time Correct function allows automatically correcting slight variation
   of your key touching manner."  --  Roland MSQ-700 manual