Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: Symlink locking considered useless over NFS
Summary: NFS is not stateless
Message-ID: <98674@sgi.sgi.com>
Date: 22 Apr 91 16:34:45 GMT
References: <3064@cirrusl.UUCP> <280EE8A1.30D@tct.com> <28124239.17CE@tct.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 39

In article <28124239.17CE@tct.com>, chip@tct.com (Chip Salzenberg) writes:
> According to thurlow@convex.com (Robert Thurlow):
> >C'mon Chip, flame in the right direction.  The lack of support for
> >O_EXCL in the create operation of NFS isn't a feature of statelessness,
> >it's just a simple-minded protocol bug.
> 
> I don't understand.  How can the server know that it's me
> re-requesting an already-successful creation, and not some other
> process on the client machine asking to create the same file?
> 
> (Please note that solutions based on keeping transaction info for the
> last N seconds are NOT acceptable, as the network cable might be
> disconnected for N+1 seconds.)


NFS without the XID cache is broken.  Try it; you'll hate it.
NFS is emphatically not "stateless."  NFS is "relatively stateless,
particularly when compared to other network file systems also designed in
the early and mid 1980's, such as the AT&T RFS."

The "NFS is stateless" cliche is partly marketing hype from the NFS/RFS
war, and partly a descriptive slogan for the design principle of avoiding
state when possible and of exploiting the consequent rebustness against
server, client, and network failures or scaling problems.

If you dislike NFS, then please switch to RFS, AFS, or your own design.
Non-constructive complaints about basic NFS design principles are as
interesting in comp.protocols.nfs as the perennial H.R. complaints in
comp.arch about high level languages hiding machine code arcana.

The O_EXCL hole is universially considered a bug, and always named as
something to fix in the next protocol turn.  I think it was fixed in
Rusty's final proposals.  Unfortunately, the only organization that could
change the protocol has been having difficulties.
(No, I don't see how the IETF can do anything but make things worse.)



Vernon Schryver,   vjs@sgi.com