(was slashes, now NFS devices)

[Barry Margolin]

In article <12662:Mar620:02:2491 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <GLX9W24 at xds13.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>> > 2. This is probably most important.  NFS is stateless.
>> This is the killer. I think it would be reasonable to relax statelessness
>> for devices, though.
>
>Why do you think so?
>
>Any argument you come up with will apply equally well to files.
>
>FILES ARE STATE.

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.  That is the state that is referred to in the
"statelessness" of NFS.  For instance, the server doesn't keep track of a
client's current position; instead, each read or write operation specifies
the offset into the file.

Devices, however, often require per-client and/or per-process state to be
maintained.  Tape devices are the best example.  Only one process is
generally allowed to access a tape device at a time, so there must be a
form of locking; this can't be done by the client machines using a locking
protocol as it is for lockf() because (in a scheme where devices are
interpreted by the server) the clients don't know that the file is a device
that must be locked.  Tape drivers often need to perform special operations
when they are first opened or all the processes using them have closed them
(e.g. rewinding the tape); this requires maintaining state about how many
clients have a device open.  The tape's current position is state that is
generally is lost across a reboot (unlike a file's contents).

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.  This would be passed along with the next
operation, and the server would have to do whatever is necessary to restore
the file to that state before performing the operation (caching in the
server can make this relatively painless in the usual cases).  The protocol
would have to include operations that indicate that the client has opened
or closed the stream, so that the special processing can be done.  The
server would also have to be able to deal with responses indicating that
the state cannot be returned to (for instance, if the server has been
rebooted and the tape unmounted, it would be difficult to forward-skip the
tape to its last position); this is analogous to NFS's "stale file handle".

This state object is effectively implicit in the current NFS protocol.  If
a client is doing stream-oriented I/O to a file, the "state" is the file
handle and the current position, which is simply the offset+length from the
last operation.
--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar