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