Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!tymix!cirrusl!sunstorm!dhesi
From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Newsgroups: comp.unix.internals
Subject: Re: (was slashes, now NFS devices)
Message-ID: <2993@cirrusl.UUCP>
Date: 9 Mar 91 21:36:39 GMT
References: <12662:Mar620:02:2491@kramden.acf.nyu.edu> <1991Mar6.231519.8393@Think.COM> <12713:Mar708:07:3591@kramden.acf.nyu.edu> <1991Mar8.074048.13105@Think.COM>
Sender: news@cirrusl.UUCP
Organization: Cirrus Logic Inc.
Lines: 51

In <1991Mar8.074048.13105@Think.COM> barmar@think.com (Barry Margolin) writes:

     NFS is just a communications protocol, a conduit.  The file system
     at the other end of this conduit maintains state, but the conduit
     itself doesn't.  NFS maintains about as much state as a disk
     cable.

This an interesting point of view.  Let's take this point of view and
analyze the situation.

When NFS is claimed to be stateless, there is another phenomenon that
is also being referred to.  The lack of state is really an inadequate
communication between the server's filesystem and the client's
filesystem:  one does not know everything about what the other is
doing.  When a process on a server unlinks a file that is still opened
on the client, NFS's statefullness or statelessness isn't the problem.
The problem is that the server's state does not include the client's
state.

NFS, as a communication protocol, could be stateless, but the server
could still know what a client is up to.  It could maintain, in addition
to its own state for the benefit of local processes, some idea of the
state of the client.  For example, once a file was opened by a client,
the server filesystem could increment some reference count somewhere,
and decrement it only when either the client closed the file, or the
client did not do any further operations on that file for some timeout
period (e.g. 24 hours).  If the client crashed, the server would not
wait forever; if the server crashed, this extra information might be
lost; but in 99% of the cases, the problem caused by a file being
deleted on the server while still in use on the client would be
avoided.  And NFS itself would still be stateless -- if you consider it
to be just a communication protocol.

So when we say that "you shouldn't delete a binary on a server while
it's being executed on a client, because NFS is stateless", we are really
saying "you shouldn't delete a binary on a server while it's being
executed on a client, because NFS as a communication protocol is
*incomplete*, and there is information useful to a server that it does
not receive from clients."

By the way, I don't believe in the common "statelessness is desirable"
argument.  Crash-resistance is desirable, and statelessness is merely a
means to that end, not the end in itself.  Statelessness could be
thought of as a necessary evil.  The question is, is there enough
counterbalancing good resulting from its existence?  Having seen many
servers go crazy with an 8-10 load average because a binary got deleted
while it was still executing on a client, I'm not convinced that there
is.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi