Paul J Stevens wrote:
/tmp is bit over 200 megs and is UFS.
That's way too small. That means /tmp will overflow if dbmail is
processing 200 megs of email at a time (lmtp+pop3+imap).
Well, it has worked on multiple servers for over 5 years now, some of
them web server, some do very nasty java stuff. I've never ran out of
/tmp space before.
200+ megs was also freebsd's 'default' years back if I remember
correctly. Now it's something like 1 gig.
The whole idea of using a filebased stream, rather than a memory based
stream was that we want to be able to handle very large messages with
running out of memory too fast. Disks are cheaper than RAM, and I assume
you have more than 200M ram, right?
Of course the price to pay is speed, so I think we'll end up making the
selection of the type of gmimestream a config option.
Would be very nice. I'd like to re-locate the temp files dbmail makes to
another area since increasing the /tmp is pretty much out of the
question. Unless I rebuild the server.
Maybe not so bad idea, I've been itching to try out the new ZFS
implementation.
Aaron:
The tmpfs is also a very very very nice thing, works wonderfully on my
Solaris boxes :) The only catch after that is to have 4G+ of memory for
it to be really useful.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
