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'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?) Any thoughts?
> Any thoughts?Could the location be made dependant on the file size? My usual setup is mfs on /tmp and ffs on /var/tmp, so /tmp being smaller and faster and /var/tmp being larger and slower.
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
Den 14.07.2010 22:34, skrev Timo Sirainen:> 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'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?) > > Any thoughts? > >I'd like to have /tmp as a default, but a variable to set it if the need is there. Much like default /tmp on MySQL works a long time, until you need to ALTER TABLE on that 30 GB table ;) Arne
Timo Sirainen put forth on 7/14/2010 3:34 PM:> Any thoughts?Don't rely on an existing temp directory. Create /var/spool/dovecot/ and /var/spool/dovecot/tmp/ with the installation script and assign the appropriate permissions. This solves the current problem and gives you a dedicated dovecot spool directory to use in the future for other functions/features. -- Stan
1.
If know you are delivering to Maildir, and you know the folder you are
delivering to, then surely you have a temporary directory in the "tmp"
out of Maildir's {new,cur,tmp} ? And also the potential benefit of being
able to rename the resulting file into the "new" directory.
2.
I would like to have the temporary directory be configurable (but with a
sane default like /tmp or perhaps /tmp/dovecot).
In an installation where Dovecot is being used heavily, people might
want to assign specific resources for Dovecot operation. So someone
might decide that Dovecot should have a specific device (hard disk /
solid state disk / whatever) for its temporary files, other than the
default /tmp.
Bill
On Wed, Jul 14, 2010 at 09:34:52PM +0100, Timo Sirainen wrote: [...]> 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) toOn Solaris, this is the situation, though it's not called ramfs but: lgb at hydra:/tmp$ uname -a SunOS hydra 5.10 Generic_141444-09 sun4v sparc SUNW,Sun-Fire-T200 lgb at hydra:/tmp$ df -h . Filesystem size used avail capacity Mounted on swap 16G 0K 16G 0% /tmp lgb at hydra:/tmp$ swap -l swapfile dev swaplo blocks free /dev/zvol/dsk/rpool/swap 256,1 16 33554416 33554416 Yes, this machine has some RAM and enough swap zvol as well, but still there can be machines with less resources too, and in Solaris /tmp is not a "normal" filesystem anyway ... /var/tmp is available though, and it's a "normal" filesystem ...