NFS and kernels ...while you're at it..

Todd Fries (tfries@umr.edu)
Mon, 26 Jun 1995 07:35:12 -0500 (CDT)

> NFS has some strange requirements. Firstly due to brain damage in the
> design you need very fast turn around of attributes and similar queries.
> Secondly you have this bogoid ope4n by inode need.
>
> > occured to me. However, along with Linus's intention to make the
> > buffer cache addressable by inode/offset, this change could make
> > implementation of NFS and HFS much cleaner, with negligible impact on
> > the other filesystems.
>
> I'm waiting for Linus on this very much - double/treble NFS speed is
> easy once this change is made.

While you guys are at rewriting nfs and restructuring a few things, I believe
now would be an appropriate time to consider writing something along the lines of
Sun's cache-fs .... for nfs or any 'network-based' filesystem, for that matter..

Basically, when you mount an nfs point, you have a portion of the disk reserved for
cache-fs, which 'caches' the nfs reads to the local hard drive. So if I compile
a huge project on my cs account (which could be on any 1 of about 20 machines),
the 1st time I compile/access each file, it is a standard nfs-read slow-speed..

But after the 1st time, it is read off the local hard drive using the cache-fs..

It is a sun-proprietary thing, but that doesn't stop us from taking the concept and
implementing it, does it? I could probably get more details, or I'm sure some of you
already know more details, but that's what I know to suggest at thist time..

It's at least worth considering...along with a possible optional/standard kerberos
type of authentication for nfs, also part of the sun-distributed nfs...

-- 
Todd Fries...tfries@umr.edu