Path: utzoo!news-server.csri.toronto.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: (was slashes, now NFS devices)
Message-ID: <20375:Mar906:16:4291@kramden.acf.nyu.edu>
Date: 9 Mar 91 06:16:42 GMT
References: <1991Mar6.231519.8393@Think.COM> <12713:Mar708:07:3591@kramden.acf.nyu.edu> <1991Mar8.074048.13105@Think.COM>
Organization: IR
Lines: 25

NFS is (supposedly) a filesystem. Somewhere inside the implementation is
the NFS protocol.

The NFS protocol was designed so that the server does not need to carry
any state other than that provided by the server machine's filesystem.
This is a perfectly reasonable design decision; any remote filesystem
can be handled this way, though it is generally more efficient to have
the server cache some information.

Many people look at this property of the NFS protocol and say ``NFS is
stateless.'' Do they think anybody cares about a minor design decision
which has no effect on the NFS filesystem interface? No. What they're
trying to do is explain why NFS handles ``stateful'' things incorrectly:
locking still doesn't work right, devices don't work, etc.

What these people are missing is that this ``statelessness'' is
absolutely irrelevant to the external NFS filesystem. Files have state,
and somehow NFS manages to work for files even though the server process
doesn't keep its own state. Similarly, just because devices have state
does *not* mean that NFS needs a ``fundamental change'' for them to
work.

[unmount /soapbox]

---Dan