Hello. I already mentioned this topic several years ago, and described a technique I used to compensate the problem at this time (and it is still usable and in use today).
The problem is that on typical workstation or any other non-mail-heavy-load machine, postfix in its default configuration constantly triggeres filesystem writes, which results in either disks spinning up or SSDs doing writes where they can just idle. This happens due to master constantly (every 5 minutes by default) poking qmgr to re-scan its queues. This is done by writing a byte into public/qmgr pipe, which triggers mtime update on filesystem level, which in turn results in a write - single write every 5 minutes, and this happens all the time even if the system does not deliver any mail at all. All major Unixes these days have one or another sort of tmpfs filesystem - a filesystem residing in RAM entirely (or it might be backed up by swap storage) but acting as a regular filesystem. Files on such filesystem aren't preserved during reboot obviously. The "trick" I use with postfix for a long time locally to address this issue is to mount a tmpfs on linux on /var/spool/postfix/run, create subdirs (pid, public, private) there and replace the corresponding subdirs in /var/spool/postfix to symlinks to these directories. Separate /run is to avoid the need to create several filesystems (one for each of pid/, public/ and private/). This works, but postfix complains that it finds dirs with "wrong" permissions (the symlinks have 0777 mode). So, the question is: can postfix change the paths so that all these "runtime" dirs are in a single subdir (as run/pid, run/public, run/private) - that is changing 3 strings in postfix code (and postfix-files) and adding one extra line into postfix-files, -- in order to simplify such a setup ? I'm fine to change postfix-files locally so it looks at run/pid etc instead of pid, but that appears to be a bit ugly... (One can argue the same writes will happen due to atime updates on the directories qmgr scans, but again, many modern OSes addressed this problem already, by - optionally - omitting atime updates if atime already greather than mtime (on linux, this mount option is named relatime, and is on by default on modern kernels)) Thanks! /mjt
