3B2/600 questions

[Leslie Mikesell]

In article <1262 at atha.AthabascaU.CA> rwa at cs.AthabascaU.CA (Ross Alexander) writes:
[re: RFS]
>I see some real interoperability
>problems here :-), not everyone is prepared to chuck their current
>hardware after picking up a 3b2/<nnn>. 
[...]
>RFS is no speed daemon :-) either, and has real
>problems when the server or client crashes.  I ran one for a while,
>and every time we lost a node, I had to shut it down on all the
>others, reboot the deader, and then start it up again all around the
>net.

If your machines crash often enough to be a problem maybe you *should*
replace them...

Anyway, you should not have to restart RFS because any single node
goes away.  As long as the primary name server is running, you should
be able to reboot any other machine and the automatic adv's and mounts
will take care of themselves.  If you designate one or more secondary
nameservers you can also reboot the primary and have it pick up the
currently advertised names by doing an "rfadmin -p" at the secondary.
Without a secondary namserver you would still only have to re-advertise
everything after rebooting the primary.  Currently active links between
other machines would not be affected.  You do lose any processes that
happen to be using an RFS directory that goes away.

>I _do_ like the way RFS allows sharing periperals like tape drives.
>That's really handy.

Actually I think this is a bad idea compared to providing server programs
that know how to handle both the network and device efficiently.  There
are also problems with ioctl()'s to devices when the CPU's are different.

>RFS does much more correctly support un*x
>filesystem semantics.  It does locking without funky locking and
>status daemons (lockd and statd).

This is indeed nice, as is the ability to make a FIFO that appears on
multiple machines and works with programs that think it is an ordinary
file.

Les Mikesell
  les at chinet.chi.il.us