heinhuis@dri.nl (Gustaaf-Jan Heinhuis) (03/21/91)
Being new to news I hope some of you out there can help me with a
problem.
I'm, together with a fellow student (Gerti Schoemaker), working on
a graduation project in computer science concerning NFS.
For those who want to know, we study at the HIO in Enschede which
is a department of the Higher Technical School. Those who are
familiar with the Dutch school system will know what this is.
Back to the problem. We know that with NFS one can't share peripheral
devices. What we would like to know is:
1) why this isn't possible,
2) if you have a neat way to get around this .
(e.g. for back up's we use:
find / -print | cpio -ocv | rsh <system name> dd of=/dev/rmt0 bs=5k)
In the "Network User's and Administrator's Guide Vol.2" for the
ICL DRS6000 running system V.4 I found the following:
"The objects that can be shared through NFS include any
whole or partial directory tree or file hierarchy-including
a single file. A machine cannot share a file hierarchy that
overlaps one that is already shared. Special device files,
as well as ordinary files, can de shared over NFS; however,
peripheral devices such as modems and printers cannot be shared."
I'd very much like to know what, in this context and in general, is meant
by "special device files". I, in my innocence, would say such a file
represents a device (like a printer), but apparently I'm wrong.
If it is possible with NFS to share printers and alike we would like to
know how this is done.
Gustaaf-Jan Heinhuis & Gerti Schoemaker.
heinhuis@dri.nl schoemak@dri.nl
***************** I is a brane *****************mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/26/91)
In article <945@dri500.dri.nl>, heinhuis@dri.nl (Gustaaf-Jan Heinhuis) writes: > "The objects that can be shared through NFS include any whole > or partial directory tree or file hierarchy-including a single > file. A machine cannot share a file hierarchy that overlaps > one that is already shared. Special device files, as well as > ordinary files, can de shared over NFS; however, peripheral > devices such as modems and printers cannot be shared." > I'd very much like to know what, in this context and in general, is > meant by "special device files". I, in my innocence, would say such > a file represents a device (like a printer), but apparently I'm > wrong. You are both right and wrong. That is to say, you are partially right. A special device file is something like all those things that clutter up /dev. The only thing that is shared is that aspect of it which is stored in the filesystem, which (aside from things, like permission bits, which all files have) is the <major,minor> device number pair (and the bit saying whether it's a block special or character special device, which is a bit of a fossil). To this extent, special device files can be shared. That is to say: server# mkdir /gleep server# mknod /gleep/foo c 107 130 (Now, /gleep/foo is a "special device file" on the server. I'll get to what this means in a minute.) server# exportfs /gleep -o access=client,rw=client (Using Sun's exportfs syntax for lack of any other accessible to me. This tells the server that `client' is allowed to nfs-mount /gleep.) client# mount server:/gleep /gloop Now, /gloop/foo is a special device file on the client. This is the sense in which they can be shared. Now, in what sense are they not shared? To explain this, and to understand the apparent contradiction in your quote from the manual, we need to delve into just what a special device file does. The utility of a device special file is that it allows access to a device. This may seem obvious, but the reason I mention is that the crucial question to ask is *how* it does this. How is the connection made between the string "/dev/tty03" and the third line on that serial line card in the machine? Well, part of that we know already. /dev/tty03 is a special device file with <major,minor> numbers <22,3> (say). Where do we go from there? We go into the kernel. In the code that implements the open() syscall, we find a check for special device files. In the case of a character special device file (block special files are identical for the purposes of this discussion), the major number (22 in my example) is used as an index into a table (traditionally called `cdevsw') which is compiled into the kernel. This table entry contains pointers to a handful of functions which are responsible for interfacing between the software and the hardware. (These functions are collectively referred to as a "device driver".) One of these is the open function; open calls this. (What happens to the minor number? That's one of the things passed to the driver's open routine.) All access to the device goes through these function pointers. When you write to it, for example, it ends up calling the driver's write routine. Now, enter NFS. Suppose the client gets the /gloop/foo special device via NFS. What happens when it's accessed? Well, the kernel will notice that it's a character special device <107,130> and go looking in cdevsw for entry 107, then call the open routine and tell it to open minor device 130. -- but wait a minute. This all happens on the client. It's the *client's* cdevsw that's used and it's the *client's* driver (if any) that gets called and it's the *client's* hardware that the driver speaks to. Not the server's. Thus, you see, while special device files may be shared, the hardware they refer to isn't, simply because the device file doesn't really carry the connection to the hardware; all it carries is a pointer into the kernel data structures and thence to the hardware. So what hardware is accessed depends on whose kernel handles the access attempt. I hope I haven't been too obfuscatory here; if there's anything still unclear about it, feel free to send me mail. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
kensmith@cs.Buffalo.EDU (Ken Smith) (03/26/91)
In article <1991Mar26.073554.2230@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: |> |> <a great explanation of how special files are treated by NFS...> |> Just a few minor things to add for the curious... Allowing you to really access a remote device rather than having all devices treated as local is the only thing I've seen that RFS (AT&T's version of remote file sharing) lets you do that NFS does not. However the reason that you get this capability is that each time you try and access a remote partition under RFS it packs up the request at the system call level and ships it off to the server. The system call gets executed on the server. This means, as far as I can tell, you could never have a completely diskless machine using RFS because it could never access its own keyboard, serial port, etc. Anyway I got my masters by extending SunOS so that you could access remote devices as if they were local. Basically it involved making a new file type called a ``remlink'' that looked sort of like a symbolic link but stashed enough information in it to define a server as well as a pathname. When this was opened a new set of vnodeops handled connecting to a daemon on the server. The daemon handled requests like opening the device, read/write, ioctl, etc. This system was designed to run alongside NFS, providing extra services that NFS couldn't (and shouldn't since as far as I can tell providing that service would violate most of NFS's basic design goals, like transparent crash recovery). -- Ken Smith internet: kensmith@cs.buffalo.edu "The seaweed is always greener in bitnet: kensmith@sunybcs somebody else's lake." -Sebastian