Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.unix.internals Subject: Re: (was slashes, now NFS devices) Message-ID: <1991Mar6.231519.8393@Think.COM> Date: 6 Mar 91 23:15:19 GMT References: <12662:Mar620:02:2491@kramden.acf.nyu.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 53 In article <12662:Mar620:02:2491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article peter@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@think.com {uunet,harvard}!think!barmar