Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!hsdndev!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: <12713:Mar708:07:3591@kramden.acf.nyu.edu>
Date: 7 Mar 91 08:07:35 GMT
References: <GLX9W24@xds13.ferranti.com> <12662:Mar620:02:2491@kramden.acf.nyu.edu> <1991Mar6.231519.8393@Think.COM>
Organization: IR
Lines: 47

In article <1991Mar6.231519.8393@Think.COM> barmar@think.com (Barry Margolin) writes:
> Yes, files have state, but NFS *servers* don't have to maintain any state
> other than the file contents; specifically, there's no per-client or
> per-process state.

It is irrelevant whether the information is physically kept in the
server, in the server's filesystem, or in the client. NFS is a protocol
with state. A filesystem without state is a useless filesystem, because
by definition it cannot carry any information.

> The tape's current position is state that is
> generally is lost across a reboot (unlike a file's contents).

Ah. So you're saying that NFS is stateless, because its implementation
just happens to succeed upon regular files and fail upon device files
through a reboot. Are you saying ``stateless'' means ``unreliable''?

Stop thinking about NFS from inside the implementation. The user sees a
*filesystem*. That means a set of files with certain semantics,
including preserved state as long as the user's machine is up. Devices
keep a different kind of state from regular files, but they're part of
the filesystem, and there's nothing about the filesystem that singles
them out.

When people say ``NFS is stateless'' they don't really mean that NFS is
a stateless (hence useless) filesystem. They really mean ``The NFS
client keeps all per-process information.'' So what? That's one strategy
for implementing a distributed filesystem. It doesn't make the
filesystem ``stateless,'' and it should not be an excuse for abysmally
unreliable and inaccurate behavior.

> One way for a stateless file protocol to deal with stream devices is for
> the response to each stream operation to include data that encodes the
> current state of the file.

Obviously this is the only way to go if the client keeps all per-process
information. So what? It is not a fundamental change in the protocol or
in any design principles of that protocol for devices to work correctly
(or for EDQUOT to work correctly). It's just a different type of
information being shuttled across, instead of the information that's
already stored in the client.

NFS has state. NFS has always had state. I am sick of Sun using the
meaningless banner of ``statelessness'' to excuse itself from fixing its
filesystem.

---Dan