GNU Info

(am-utils.info)Centralized Mail Spool Directory

---

Next: Distributed Mail Spool Service Prev: Single-Host Mail Spool Directory Up: Background to Mail Delivery

---

Enter node , (file) or (file)node

Centralized Mail Spool Directory
--------------------------------

   A popular method for providing mail readability from any host is to
have all mail delivered to a mail spool directory on a designated
"mail-server" which is exported via NFS to all of the hosts on the
network.  Configuring such a system is relatively easy.  On most
systems, the bulk of the work is a one-time addition to one or two
configuration files in `/etc'.  The file-server's spool directory is
then hard-mounted across every machine on the local network.  In small
environments with only a handful of hosts this can be an acceptable
solution.  In our department, with a couple of hundred active hosts and
thousands of mail messages processed daily, this was deemed completely
unacceptable, as it introduced several types of problems:

Scalability and Performance
     As more and more machines get added to the network, more mail
     traffic has to go over NFS to and from the mail-server. Users like
     to run mail-watchers, and read their mail often. The stress on the
     shared infrastructure increases with every user and host added;
     loads on the mail server would most certainly be high since all
     mail delivery goes through that one machine.(1)  This leads to
     lower reliability and performance.  To reduce the number of
     concurrent connections between clients and the server host, some
     SAs have resorted to automounting the mail-spool directory.  But
     this solution only makes things worse: since users often run mail
     watchers, and many popular applications such as `trn', `emacs',
     `csh' or `ksh' check periodically for new mail, the automounted
     directory would be effectively permanently mounted.  If it gets
     unmounted automatically by the automounter program, it is most
     likely to get mounted shortly afterwards, consuming more I/O
     resources by the constant cycle of mount and umount calls.

Reliability
     The mail-server host and its network connectivity must be very
     reliable.  Worse, since the spool directory has to be
     hard-mounted,(2) many processes which access the spool directory
     (various shells, `login', `emacs', etc.)  would be hung as long as
     connectivity to the mail-server is severed. To improve
     reliability, SAs may choose to backup the mail-server's spool
     partition several times a day.  This may make things worse since
     reading or delivering mail while backups are in progress may cause
     backups to be inconsistent; more backups consume more backup-media
     resources, and increase the load on the mail-server host.

   ---------- Footnotes ----------

   (1)  Delivery via NFS-mounted filesystems may require usage of
`rpc.lockd' and `rpc.statd' to provide distributed file-locking, both
of which are widely regarded as unstable and unreliable.  Furthermore,
this will degrade performance, as local processes as well as remote
`nfsd' processes are kept busy.

   (2) No SA in their right minds would soft-mount read/write
partitions -- the chances for data loss are too great.