I'm having trouble creating a named pipe on a filesystem mounted from a 760 to a Linux system. The 760 is running 5.3.4R3.
'mknod <name> p' gives me a zero-length file rather than a named pipe:
# mknod initctl p # ls -la initctl -rw-r--r-- 1 root root 0 Feb 8 15:58 initctl ^
I'm sure this *used* to work (way back when I had a 540). It works fine if I try it on a filesystem mounted from a Linux server...
Any ideas?
-Ronan
It works fine on Solaris 2.6 with 5.3.4R2P2 on a 760 on the back side.
Tom
On Tue, 8 Feb 2000, Ronan Mullally wrote:
I'm having trouble creating a named pipe on a filesystem mounted from a 760 to a Linux system. The 760 is running 5.3.4R3.
'mknod <name> p' gives me a zero-length file rather than a named pipe:
# mknod initctl p # ls -la initctl -rw-r--r-- 1 root root 0 Feb 8 15:58 initctl ^
I'm sure this *used* to work (way back when I had a 540). It works fine if I try it on a filesystem mounted from a Linux server...
Any ideas?
-Ronan
On Tue, 8 Feb 2000 tkaczma@gryf.net wrote:
It works fine on Solaris 2.6 with 5.3.4R2P2 on a 760 on the back side.
It looks like Linux may be the culprit. I've been able to create pipes using NFS v2 and v3 on my HP-UX boxes, and you and others have had no problems with FreeBSD and Solaris. I'll follow it up with the Linux folks...
-Ronan
On Tue, Feb 08, 2000 at 10:13:50PM +0000, Ronan Mullally wrote:
It looks like Linux may be the culprit. I've been able to create pipes using NFS v2 and v3 on my HP-UX boxes, and you and others have had no problems with FreeBSD and Solaris. I'll follow it up with the Linux folks...
Linux is indeed the culprit. I did a little investigating and this behavior is coded into the Linux kernel itself. Here are some details...
It looks like when defining the filesystem type in the Linux kernel, filesystems which allow mounting with the "dev" ("mount -o dev ...") option needs to be specified with the "FS_REQUIRES_DEV" flag.
I checked both the latest stable (2.2.14) and development (2.3.42) kernels and found this in fs/nfs/inode.c:
/* * File system information */ static struct file_system_type nfs_fs_type = { "nfs", 0 /* FS_NO_DCACHE - this doesn't work right now*/, nfs_read_super, NULL };
Compare this to a filesystem which allows the "dev" option to mount (in fs/ext2/super.c):
static struct file_system_type ext2_fs_type = { "ext2", FS_REQUIRES_DEV /* | FS_IBASKET */, /* ibaskets have unresolved bugs */ ext2_read_super, NULL };
So basically, whatever you do with "mount" from the user command regarding "dev" or "nodev" with an NFS filesystem will have no effect in the Linux kernel; it will always be "nodev".
I don't know why it is done this way. I'm guesssing that it could be deemed a security hazzard to allow interpretting special devices over NFS, so making an NFS mount permanently "nodev" is one possible solution.
You *might* be able to put "FS_REQUIRES_DEV" for nfs_fs_type, but I have no idea if this will work or what other problems it could cause. Someone will have to check with the Linux kernel folks on this one.
regards, --andy
I'm sure this *used* to work (way back when I had a 540). It works fine if I try it on a filesystem mounted from a Linux server...
Works fine under real operating systems:
: pancake:/home/n/nick> mknod foo p : pancake:/home/n/nick> ls -al foo : prw-r--r-- 1 nick 128 0 Feb 8 17:59 foo| : pancake:/home/n/nick> uname : FreeBSD
Are you mounting the filesystem with "nodev"?
Nick
[P.S. no flames, please. This is a private joke.]
On Tue, 8 Feb 2000, Nick Hilliard wrote:
I'm sure this *used* to work (way back when I had a 540). It works fine if I try it on a filesystem mounted from a Linux server...
Works fine under real operating systems:
: pancake:/home/n/nick> mknod foo p : pancake:/home/n/nick> ls -al foo : prw-r--r-- 1 nick 128 0 Feb 8 17:59 foo| : pancake:/home/n/nick> uname : FreeBSD
Bugger. Chalk up another point for BSD. Are you using NFSv3?
Are you mounting the filesystem with "nodev"?
*Ahem*.
I've done a few packet traces and come up with the following (payloads omitted):
mknod on a filesystem originating from a Linux server:
eth0 < bosco.1188064005 > wumpus.nfs: 140 lookup [|nfs] eth0 > wumpus.nfs > bosco.1188064005: reply ok 28 lookup ERROR: \ No such file or directory eth0 < bosco.1204841221 > wumpus.nfs: 172 create [|nfs] eth0 > wumpus.nfs > bosco.1204841221: reply ok 128 create fh Unknown/1
mknod on a filesystem originating from a toaster:
eth0 > wumpus.3096735938 > podge.nfs: 152 lookup [|nfs] eth0 < podge.nfs > wumpus.3096735938: reply ok 28 lookup ERROR: \ No such file or directory eth0 > wumpus.3113513154 > podge.nfs: 184 create [|nfs] eth0 < podge.nfs > wumpus.3113513154: reply ok 128 create fh Unknown/1
Anybody who can shed some light on this gets a pint :)
-Ronan