Given
the very specific nature of
the subject (we're not talking about mailboxes, just
the spool; we're not talking about other filesystems, just ext3; and so on...) and
the maturity of
the softwares involved (linux kernel, ext3fs, postfix) I'd think there should be a more or less agreed on set of best practices to filesystem related tuning.
I'm trying to get a roundup of them:
data=journal became
the default in recent kernels (somewhere around 2.6.30 IIRC) so we should be ok with that
Wietse Venema says atime must be on, but Postfix
documentation recommendsnoatime while talking about
the Incoming Queue. Does that mean that postfix needs atime on just for some queue directories and will benefit from noatime on
the others? can we use noatime if we just don't use ETRN?
filesystem can be mounted nodev,noexec,nosuid - no* won't prevent you from setting attributes (postfix uses exec attr) they just won't have any effect (we don't run anything from
the spool)
the fsync() issue cited by Wietse and/or
the chattr -S are probably linked to sync/async options of ext3fs but I do not understand them enough. Mouting
the filesystem with async option is equivalent to chattr -R -S
the whole fs? Seems like it will increase performance, but will that pose a risk of "loss of mail after a system crash" or is it really "safe on /var/spool/postfix" ?
would you tune anything else on postfix-2.6.x to work better on ext3 or do you leave defaults everywhere?
is there a "best" linux I/O scheduler for this kind of workload (namely CFQ or deadline?) or that's something that will vary too much based on hardware configuration?
would you tune anything else in
the filesystem or in
the kernel?
anything else?
References:
Postfix Performance here on SF
Postfix
documentation about
the Incoming Queue
Wietse Venema in Best file system on
[email protected] here
Postfix and ext3 on
[email protected] here and there