Something I'd really like to see added to NetBSD is the option of
caching NFS in VM.

Justification:  My basic assumption is that there are times when it's
much preferable to grab info off a local disk than off an NFS server.
The general situations when you'd want this would be when your server
or your network is overloaded.  More specifically, you could setup a
lab full of remote-booting workstations that grab all their files off
of NFS, but cache everything to a local paging device.  This whole
scheme assumes that VM management is somewhat efficient, which I think
it is.

Particulars:  To keep things relatively simple, it seems that a
command-line option to nfsiod would work well.  Unless there's a
better way to do this, nfsiod could malloc a huge chunk of VM (size
determined by the command-line option), and the kernel would store NFS
blocks in this cache.  My hope is that this VM would be managed
appropriately based on how recently a given piece of the cache had
been accessed; that's the point of paging, after all.

I figure most people wouldn't want a cache like this, so nfsiod would
continue its current behavior unless it was told otherwise.

Questions:  0.  Is this whole scheme even a good idea?  For instance,
is there something in the NFS spec(s) that prohibits this sort of
long-term caching?

1.  It seems like a good idea to have an index of the contents of the
cache along with the cache in user-space.  The index would be more
likely to be in core than the cache itself, which means the individual
index entries need to be small.  How can I represent index information
without using NFS_MAXPATHLEN bytes for the filename?  (If all else
fails, I can hash the filename to see if it's in the cache -- that'll
usually be right -- but it adds another layer of complexity to the
whole thing.)

2.  Is there a nice, little "intro to kernel programming" that I
should read?  I've looked at the style guide, and I know where the
source is, but an intro wouldn't hurt.

Chris

-- 
-------------------------------------------------------------------------------
Chris Jones                                      cjones@rupert.oscs.montana.edu
           Mad scientist in training...
"Is this going to be a stand-up programming session, sir, or another bug hunt?"