haynes@ucscc.UCSC.EDU (99700000) (07/19/90)
In article <1990Jul18.215830.4385@laguna.ccsf.caltech.edu> ktl@wag240.caltech.edu (Kian-Tat Lim) writes: > > In order to provide our users with a more transparent view of >our network, we plan to centralize our /usr/spool/mail files on one >machine, using NFS and symbolic links to access them on the others. > Seems to me one thing you need to worry about is whether it scales. I'm aware that at MIT Project Athena they send the mail to three post office servers, because they are serving 1000 workstations. I'm not sure how many workstations you can serve with NFS mounting a single /usr/spool/mail versus something like the post office protocol that they use. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
karl_kleinpaste@cis.ohio-state.edu (07/19/90)
haynes@ucscc.ucsc.edu writes: > In order to provide our users with a more transparent view of > our network, we plan to centralize our /usr/spool/mail files on one > machine, using NFS and symbolic links to access them on the others. Seems to me one thing you need to worry about is whether it scales. I think it scales fine. We use a single /usr/spool/mail mounted on ~400 machines and have no trouble. The one thing you'll really need to worry about is having an rpc.mountd which can cope with the abuse inflicted by the booting of one's entire network; cf. discussion in comp.protocols.nfs about 2 months ago regarding rpc.mountd thrashing when too many machines are asking for filesystems. Oh, you'll also want to modify /bin/mail to be resilient to NFS timeouts. We soft-mount /usr/spool/mail on most systems, but /bin/mail must not be allowed to kick out on an NFS error. Add a pile of error-return checking and retries when errors occur. --karl -- I think that everyone's brains get scrambled one way or another. --Killashandra Ree