[comp.protocols.nfs] Diskless Workstations and /dev/nd

martillo@cpoint.UUCP (Joacim Martillo) (01/17/89)

I was just told by former Sun employees that the latest version
of NFS eliminates /dev/nd.  I guess this makes sense for file
system partitions, but I would think that for paging partitions
using a raw network device would make sense.  Is there anybody
around who can clarify this issue?

ed@mtxinu.COM (Ed Gould) (01/19/89)

>I was just told by former Sun employees that the latest version
>of NFS eliminates /dev/nd.  I guess this makes sense for file
>system partitions, but I would think that for paging partitions
>using a raw network device would make sense.  Is there anybody
>around who can clarify this issue?

That's correct.  The new diskless code (we run diskless MicroVAXen
with it) does not use ND.  ND was a hack put together in a few hours
to be able to run diskless machines before there was a reasonable
protocol available.

Running diskless without ND involves paging to a file on the server.
With the BSD fast file system, this is acceptably efficient.  The
Sun people have stated that their performance goal for diskless NFS
was to be as fast as a local SCSI disk.  While I'm not entirely
convinced that they met this goal, they at least came pretty close.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
ed@mtxinu.COM		    +1 415 644 0146

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."

liam@cs.qmc.ac.uk (William Roberts) (01/24/89)

In article <739@mtxinu.UUCP> ed@mtxinu.COM (Ed Gould) writes:
>Running diskless without ND involves paging to a file on the server.
>With the BSD fast file system, this is acceptably efficient.

Bear in mind that program text is NOT swapped in Berkeley 4.2
(or SunOS 3.x, 4.0) so that when a page of the program needs to
be reloaded into memory it is pulled back from the original
file; this is the reason why you can't write into a program
while it's being executed ("Text file busy"), unless of ocurse
it's on a remote file system :-)

This becomes annoying if you *do* have local disk, but are
executing binaries from a remote file system. As for ND, it is
interesting to note that the Project Athena system uses a
"block server" for its root (and usr?) partitions, which is at
the same level as ND and avoids the overheads incurred by
accessing files through their inodes, but only for a read-only
file system.
-- 

William Roberts         ARPA: liam@cs.qmc.ac.uk  (gw: cs.ucl.edu)
Queen Mary College      UUCP: liam@qmc-cs.UUCP
LONDON, UK              Tel:  01-975 5250