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