ok@cs.mu.oz.au (Richard O'Keefe) (10/11/89)
I am using a Sun-3/50 called mudla. Here's what /etc/motd says about it:
SunOS Release 4.0_Export (MULLO_CLIENT_50) #1: Wed May 24 18:23:08 EST 1989
My files are held on a file server called mullauna, an Encore Multimax,
and are accessed through NFS. Here's what I see when I log in on mullauna:
UNIX System V Release ax.2.2f ns32332
Now, SunOS supports named pipes, and System V supports named pipes, and
the network is the computer, so named pipes should work, not so? No.
On mullauna (the server), in my home directory:
% rm -f zabbo
% /etc/mknod zabbo p
% file zabbo
zabbo: fifo
just as I would expect.
On mudla (the client), in my home directory (the same directory):
% rm -f zabbo
% /etc/mknod zabbo p
% file zabbo
zabbo: empty
This came as a rather unpleasant surprise. To check whether SunOS really
does understand named pipes, I tried
% rm -f /tmp/zabbo
% /etc/mknod /tmp/zabbo p
% file /tmp/zabbo
/tmp/zabbo: fifo
mudla's /tmp is served from another Sun-3.
Is this supposed to work, or should I just forget about named pipes?david@elroy.jpl.nasa.gov (David Robinson) (10/12/89)
In article <2388@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
<I am using a Sun-3/50 called mudla. Here's what /etc/motd says about it:
<SunOS Release 4.0_Export (MULLO_CLIENT_50) #1: Wed May 24 18:23:08 EST 1989
<
<My files are held on a file server called mullauna, an Encore Multimax,
<and are accessed through NFS. Here's what I see when I log in on mullauna:
<UNIX System V Release ax.2.2f ns32332
<
<Now, SunOS supports named pipes, and System V supports named pipes, and
<the network is the computer, so named pipes should work, not so? No.
[Description of how it fails]
< Is this supposed to work, or should I just forget about named pipes?
Named pipes are not the the current NFS protocol (v2), but they are
supported in some NFS implementations. In SunOS 3.2 named pipes were added
and the corresponding NFSSRC 3.2(may be off on the number), which many
vendors base their NFS on, included a kludge to handle named pipes
correctly. Most vendors have picked this up but not all.
It would appear that either Encore is running an NFS based on an old
version of the reference port or they built their own from scratch.
In either case it is a problem with your vendor's code.
--
David Robinson elroy!david@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!mdash@cbnewsl.ATT.COM (michael.d.scheer) (10/12/89)
NFS does not support named pipes, because they (like devices) require state on the server, and NFS servers are stateless. FYI, RFS (that other distributed file system) does support named pipes.
ok@cs.mu.oz.au (Richard O'Keefe) (10/13/89)
In article <2229@cbnewsl.ATT.COM>, mdash@cbnewsl.ATT.COM (michael.d.scheer) writes: > NFS does not support named pipes, because they (like devices) require > state on the server, and NFS servers are stateless. FYI, RFS (that > other distributed file system) does support named pipes. A Sun-3 client running SunOS 4.0_Export _can_ create a named pipe in an NFS file system mounted from a Sun-3 server. NFS servers don't maintain _connection_ state, but surely the state which is relevant to a named pipe is the _contents_.
trt@rti.UUCP (Thomas Truscott) (10/14/89)
> > NFS does not support named pipes, because they (like devices) require > > state on the server, and NFS servers are stateless. FYI, RFS (that > > other distributed file system) does support named pipes. > > A Sun-3 client running SunOS 4.0_Export _can_ create a named pipe > in an NFS file system mounted from a Sun-3 server. > NFS servers don't maintain _connection_ state, but surely the state > which is relevant to a named pipe is the _contents_. Give me a break! Modern versions of NFS can create named pipe _entries_ in remote filesystems, but the _contents_ of the pipe never leave the client. Processes on different clients CAN NOT share data using a common named pipe, because under NFS it just doesn't work that way. Each different client gets its own local instance of the pipe. To say that "NFS supports remote named pipes" is highly misleading. FLAME ON A lot of vendor literature for improved NFS says things like "Access to named pipes and device files is now supported with NFS" (usually along with other statements such as "the network is the computer"). Your typical UNIX person might misinterpret this to mean that NFS can now share the contents of remote named pipes and that NFS can now do I/O to peripheral devices that are physically connected to remote systems. In fact, this misinterpretation happens a lot. Our group at RTI has a neat distributed file/computing system called Freedomnet, but when talking to vendors or company management the following happens all too often: FN: Freedomnet supports remote devices and named pipes. V/C: "So does NFS!" FN: Freedomnet supports all locking mechanisms. V/C: "So does NFS!" (Yeh. lock daemon from hell.) FN: Freedomnet supports remote execution. V/C. "So does NFS!" NFS does not support these things (for any normal meaning of the word "support"), and never intended to, but surprisingly few people are aware of that. You can see how this can be rather frustrating. Tom Truscott
mdash@cbnewsl.ATT.COM (michael.d.scheer) (10/14/89)
In article <2415@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >In article <2229@cbnewsl.ATT.COM>, mdash@cbnewsl.ATT.COM (michael.d.scheer) writes: >> NFS does not support named pipes, because they (like devices) require >> state on the server, and NFS servers are stateless. FYI, RFS (that >> other distributed file system) does support named pipes. > >A Sun-3 client running SunOS 4.0_Export _can_ create a named pipe >in an NFS file system mounted from a Sun-3 server. > >NFS servers don't maintain _connection_ state, but surely the state >which is relevant to a named pipe is the _contents_. The NFS server source I've seen returns EISDIR on an attempt to read other than a regular file, but I suppose that does not rule out the existence of NFS servers that do otherwise. The NFS protocol IS designed to support stateless servers, and yes, that IS statelessness with respect to the FILE. This is why the lock manager is a separate network service, not part of NFS. One happy result of this statlessness is that NFS servers don't have to do anything if a client crashes. A less happy result is that files with inherently stateful semantics (named pipes, e.g.) have not traditionally been supported by NFS.
ok@cs.mu.oz.au (Richard O'Keefe) (10/14/89)
In article <3208@rti.UUCP>, trt@rti.UUCP (Thomas Truscott) writes: > Give me a break! Modern versions of NFS can create named pipe _entries_ > in remote filesystems, but the _contents_ of the pipe never > leave the client. Processes on different clients > CAN NOT share data using a common named pipe, > because under NFS it just doesn't work that way. > Each different client gets its own local instance of the pipe. > To say that "NFS supports remote named pipes" is highly misleading. Thank you very much for the clarification. (I was careful to avoid saying that NFS supports named pipes; only to claim that I could apparently make one over NFS.) If it's not going to work, I do wish /etc/mknod would have the courtesy to report and error and not do anything rather than give me an empty file or a named pipe I can't use. > Our group at RTI has a neat distributed file/computing system > called Freedomnet ... Surely it isn't advertising if you're _asked_, so, tell us more about Freedomnet. How different is it from TCF?