Ralf Hildebrandt's "Postfix on an ext3 fs"(good!)

hzqbbc

http://www.stahl.bau.tu-bs.de/~hildeb/postfix/ext3.shtml


Postfix on an ext3 filesystem
Warning
Hein Roehrig notes: According to http://www.redhat.com/mailing-lists/ext3-users/msg07522.html there is a bug in the Linux kernel 2.4.18 and 2.5.x which makes ext3 data=journal unsafe when both mmap() and write are used on a file. db3 does exhibit this behavior.
IMHO it should be safe to use data=journal on /var/spool/postfix.


Recommended Setup
use data=journal journalling mode for the $queue_directory (usually /var/spool/postfix).
ext3 was designed to perform full data and metadata journaling. In this mode (called "data=journal" mode), the JBD journals all changes to the filesystem, whether they are made to data or metadata. Because both data and metadata are journaled, JBD can use the journal to bring both metadata and data back to a consistent state.

For the $queue_directory we get no performance penalty, because most queuefiles dont stay in the queue very long, thus they're written to the journal only and deleted from there.

mount $queue_directory using the option noatime.
Postfix doesn't care about the atime of a queuefile. Since atime updates affect the file and all directories above it, we get a performance boost by that.

Since we're using data=journal, we can safely say
chattr -R -S /var/spool/postfix
ext3 guarantees the integrity of the directory

make sure that /var/log is not using data=journal journalling mode.
data=ordered (the default) gives the same guarantees as data=journal when just appending (and you're appending to logs only!) -- while being faster.
This usually means you have to have a partition for /var/log and another one for /var/spool/postfix

Disable the write-cache for your drive:
Linux cannot currently deal with write caches in drives properly, because it cannot tell the drive when to flush the cache.
Current disk drives have big caches (2 MB and in excess of that) and can easily swallow several hundred mails at a time. You don't want that. Tagged Command Queueing (SCSI only in Linux at the moment) partially makes up for that.

Write barrier support is on its way (Chris Mason posted an alpha-quality patch to the linux-kernel and reiserfs mailing lists, it only supports ATA and AIC7XXX SCSI, but no qlogic or LSI SCSI, not sure what file systems are supported), which is supposed to run Linux safely with write caches on, but before this is solid and in the regular kernel, using write caches can kill your file system. All ATA drives I bought recently have had their caches turned on, so watch out. On SCSI, I've seen to opposite, all SCSI drives I know of have their fast write cache off.

hdparm -W0 /dev/hda

Use
elvtune -r 4096 -w 8192
for the drive containing your $queue_directory. On soft-RAID devices, you need to use elvtune on each physical drive!

I usually use:
/dev/hda3 on /     type auto (rw,errors=remount-ro)
/dev/hda1 on /boot   type ext3 (rw)
/dev/hda6 on /var/spool type ext3 (rw,data=journal,noatime)
/dev/hda7 on /var/log  type ext3 (rw)

References
The benefits of the ext3 filesystem (Part 7)
Surprises in ext3 (part 8)
Visit Andrew Morton's ext3 and 2.4 usage page to complete your ext3 setup.