Subject: Re: NFS cache in VM
To: Chris Jones <firstname.lastname@example.org>
From: Frank van der Linden <email@example.com>
Date: 02/26/1997 14:44:09
Quoting Chris Jones,
[nfsiods caching a large amount of data]
> 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?
There's nothing that prohibits it. But it's you who has to take care of
cache consistency then. Also, there are some problems with the buffer
consistency. If you're going to make this large cache part of the normal
buffer cache, you'll run out of kernel VM. If you're going to do it seperate,
things will get awfully confusing keeping your cache consistent with the
buffer cache. Also, as nfsiods are optional and an optimization, it
does read ahead/write behind operations. Not all I/O goes through them.
> 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.)
All this is already present in the kernel, there's no need to reinvent
the wheel. You could do something like attaching a pointer to a userspace
address to the nfsnode structure, if part of that file has been cached. Which
means you can just do the lookup by normal means, get the vnode, get
the nfsnode from there, etc.
> 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.
I assume that you know "Design and implementation of 4.4BSD" ? If you
don't have, you should get it, it's the closest there is.
All in all, I'd say that if you want just a practical solution, you
may be best off using NQNFS (see.. /usr/src/share/doc/smm/06.nfs I think)
with a large buffer cache, and a large lease expire time. If you want
to have a fun hacking project, then by all means, try it :-)