On 7/14/10 4:34 PM, Timo Sirainen wrote:
In v1.0 .. v1.1 deliver was writing incoming >128k mail to /tmp file (to avoid reading it all into memory). In v1.2 I moved it to user's home directory. This slowed deliveries for NFS users. Also people with filesystem quota had trouble since now user required twice as much available quota to save a message. The FS quota problem was "solved" by having quota-fs plugin change the default temp file path to /tmp.
So why was the move made in the first place? Because a) some people had small (maybe ramfs) /tmp and Dovecot was eating it all up and b) to avoid any potential security issues with storing per-user files to a shared directory. I haven't seen anywhere that /tmp is actually a ramfs, but that is besides your point. I would say that if people are using Dovecot they should be designing the partitions around the need for the software and services they are running (at least that is what I do). I'm now thinking about a new setting (mail_temp_dir?) for v2.0 where these temp files would be stored (lda, lmtp, some others in future). Maybe the b) problem isn't that huge, so maybe there doesn't need to be a way to store them to user's home. So that leaves a) problem. Maybe the setting could default to /var/tmp instead of /tmp? That probably has more disk space available usually. (I hope /var/tmp is available everywhere?) Everywhere I have seen /var/tmp used, it has been linked to /tmp. I would recommend using /tmp as the default. Also, not all distributions, including Slackware (which a lot of slack users like Dovecot) do use /var/tmp for anything, which can get confusing.
I really like the idea of a default, and then the ability to change the default. That way if people need to grow out of /tmp or wherever you decide the default is going to be, it can be moved easily.
Any thoughts?
-- Steve King
Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional