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.
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.
chattr -R -S +j +A /var/spool/postfix/It sets noatime, data=journal and async only in the $queue_directory.
chattr -R -S /var/spool/postfix
ext3 guarantees the integrity of the directory
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
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
elvtune -r 4096 -w 8192for the drive containing your $queue_directory. On soft-RAID devices, you need to use elvtune on each physical drive!
/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)
Andrew went on to say that "The symptoms are that any file data which was written within the thirty seconds prior to the unmount may not make it to disk. A workaround is to run sync' before unmounting". He also posted a patch to fix the problem. However, soon thereafter, he posted saying that "that 'fix' didn't fix it. Sorry about that". Until a proper fix can be developed, he recommends that people "please avoid ext3/data=journal". Since "data=journal" is not the default ext3 mode, it is unlikely most people running ext3 will be affected by this. However, it is a data corruption bug so you should double-check that you use either "data=ordered" or "data=writeback" as your ext3 mode of operation. "
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.
© by Ralf Hildebrandt
This document contains links to external information sources that I do neither monitor nor control. I explicitly disclaim any liabilities in respect to external references.
You are getting this document without any guarantees. Any methods shown above are meant as demonstration and may be wrong in some place. You may damage your system if you try to follow my hints and instructions. You do this at your own risk!