Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!ucsdhub!esosun!seismo!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.dcom.lans
Subject: Re: NFS vs RFS
Message-ID: <964@auspex.UUCP>
Date: 7 Feb 89 17:52:54 GMT
References: <9018@cit-vax.Caltech.Edu> <7387@chinet.chi.il.us> <463@maxim.ERBE.SE> <478@atcmpe.atcmp.nl>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21

>> The NFS locking protocol doesn't support the SVID's mandatory locking,
>> but only the advisory locking. I guess it will be hard to implement
>> mandatory locking in a stateless environment like NFS.
>
>Mandatory locking is part of SystemV Release 3, not in Berkeley releases

So? That's totally irrelevant.  *Neither* mandatory *nor* advisory
*record* locking is part of Berkeley releases; all they currently have
now is "flock".  Most systems implementing NFS aren't "Berkeley
releases"; they may have "started with 4.xBSD" but they've added a
number of other functions - mandatory locking would be just another
function. 

In fact, some systems implementing NFS *are* System V Release 3
systems....

NFS isn't a Berkeleyism.  The only hard-core Berkeleyism in the current
protocol is that many of the error numbers happen to be 4.xBSD "errno"
values (a lot of them also happen to be S5 "errno" values, since they're
really V7 "errno" values); the current NFS version 3 protocol spec
changes that - they're now not "errno" values for any UNIX version.