[comp.mail.sendmail] NFS-mounted /usr/spool/mail

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