aglew@mcdurb.Urbana.Gould.COM (05/21/89)
>Reboot an RFS server and you better reboot every client while you are about it. At my site we run maybe a dozen "backbone" machines, with two main RFS servers and most machines RFS cross-mounted to each other for convenience. We frequently reboot one, without rebooting the others. The only annoyances are (1) the messages that say "Machine XXXX is going down. Filesystem FOO will be unavailable", and (2) the delay before RFS realizes that a machine has just come back up. I will admit that we were quite afraid of problems before going from NFS to RFS, but overall RFS has been quite pleasant to work on. In particular, our site's workload used to be able to drive NFS into deadlock regularly; either our workload has changed (which it has) or RFS is slightly less deadlock prone that NFS. >Another important feature of RFS is support for device special files; >the resulting major/minor device numbers are correctly processed by the server, >rather than being interpreted relative to the client the way NFS does. This is heaven! It is just so convenient to be able to get 2 or 3 tape drives, only one local, feeding the same application. Yes... I have tried the remote tape access mechanisms on BSD - I prefer RFS, so I can do tar xf /rfs/othermachine/dev/TAPE.CART. Something I would highly recommend to any RFS site is crossmounting /dev read/write to all machines (if you don't already cross-mount the world). >To sum up, I don't mean to beat up on RFS. Given a reliable LAN with reliable >homogenous servers and clients, it delivers a much higher level of >functionality, and truly distributes the UNIX filesystem transparently. On the >other hand, hetrogenous networks with unreliable servers see better service >from NFS. > >Obviously, these are my opinions only; I would love to be taught why I am >wrong, if anybody would care to enlighten me. But please be nice:-). > >-Bennett >bet@orion.mc.duke.edu No problem. I just admit to being agreeably surprised by RFS.