>We're about to move the data on our campus mail server (45000 users, ca 60G of
>mail) to a new hunk of disk, and are evaluating our filesystem arrangement.
...
>Does anyone have experience or data on optimal sizes of filesystems?

You didn't say what your mail server software is or file system topology,
but some general feedback...

Many sites use the Sendmail package, which has historically employed a single
mail spool directory.  This is fine for a workstation or small system, but
when you are talking mail servers, this is awful.  We have some 30,000 users
on our cluster and having a large proportion of those as entries in a flat
mail spool directory was dunning for performance due to directory updating.
We modified Sendmail to apportion users to multiple mail spool file systems
and multiple subdirectories within each and reclaimed performance.  The
rule of thumb is to try to keep the number of files in any directory to
1,000 or less in order to have acceptable performance where there is a lot
of file updating, as occurs in mail delivery.

Dividing users across a reasonable number of mail spool file systems (fewer
than 10,000 users per file system) makes for much more reasonable ADSM
incremental backups as well.  (The 'df' command inode count report is just
about equal to the number of files in a file system with few subdirectories.)
Remember: it's not so much the size of the file system, but the number of
files that most delays backups (and restorals).

  Richard Sims, BU