[266] in Commercialization & Privatization of the Internet
Re: Alternatives to NFS (Was: Re: Should the NREN be funded?)
daemon@ATHENA.MIT.EDU (David Herron)
Sun Mar 3 14:54:34 1991
To: "Manavendra K. Thakur" <thakur@zerkalo.harvard.edu>
Cc: com-priv@psi.com
In-Reply-To: Your message of Sun, 03 Mar 91 04:21:32 -0500.
Date: Sun, 03 Mar 91 11:32:28 -0800
From: David Herron <david@TWG.COM>
> >>>>> On Sat, 2 Mar 91 23:14:17 -0500, stev@ftp.com (stev knowles) said:
> > the common answer i use to this question has to do with checksums.
> > Sun refuses to add checksums to NFS, for "speed considerations".
> > this causes other vendors, who simply repackage the reference port
> > of NFS, to resist changing the code.
> Apparently Sun already has added checksums to NFS - I'm told Sun's C2
> security package has that feature. I'm also told that the C2 package
> doesn't work all that well or smoothly, so perhaps in practice that is
> why you say Sun refuses to add checksums to NFS. Also, I don't know
> whether other vendors provide checksum capabilities in their
> implementations of NFS.
In current SunOS (v4.1 and v4.1.1) you can enable NFS/UDP checksums
by a kernel reconfiguration. Its turned off by default and while the
reconfiguration is pretty easy it also isn't straight forward & trivial.
It involves following some slightly confusing directions to edit a ".c"
file to change the value of a variable.
As for speed considerations: There's ~ 8% overhead (or so I've heard)
in calculating those checksums. I feel its cheap insurance, others
feel differently.
BTW .. one of the things which AT&T did well is how you reconfigure
System V. Yes it could be improved (considerably!), but its still much
better and easier than any of the BSD systems I've reconfigured.
> But I hasten to point out that adding checksums is hardly enough to
> correct the deficiencies of NFS! Largely because NFS is both
> stateless and synchronous, NFS is simply too slow and inefficient for
> building large-scale filesystems that might span nations or
> continents. Nor is there any mechanism in NFS to create and enforce a
> global namespace (except by self-imposed discipline, which is doable
> but makes NFS more difficult to administer). For these and other
> reasons, NFS is not scalable in any meaningful sense of the word.
Okay, fine, AFS.
I'm not so sure that nationwide, continentwide, or planetwide (why stop
at continents?) file systems are necessary. But if people wanna do 'em
who am I to stop it from being done? Still NFS was too clumsy to use
even "campus wide", or so my experience in Kentucky was. It worked very
well within our own department because we had control over user IDs and
the configuration of the environment .. we made heavy use of NFS and had
a very nice environment result from it. But if a server would go down
all the workstations pulling their /usr/local & /usr/lib stuff from there
would effectively lock up. Not a good thing ...
That's a reason why I would like to use some other network file system
than NFS.
> The backers of NREN would do well to look at the history of AFS as it
> developed out of university research and migrated to a commercial
> product. Presenting AFS as a case study to Congress might help
> persuade that august body to fund similar endeavors in the future to
> help fulfill both the research and educational missions of NREN.
Agreed ...
> P.S. Disclaimer - I don't work for nor do I get paid by Transarc, CMU,
> AT&T, Berkeley, or Sun.
Disclamer - we sell NFS software. I don't know what the "corporate
stance" is on any of those issues.
David
