-----BEGIN PGP SIGNED MESSAGE-----
Patrick Nagel wrote:
> Hi Ben,
> On Wednesday 14 May 2008, Ben Green wrote:
>>> In my opinion, this default setting has too much potential of causing
>>> (sometimes hard-to-debug) trouble. The few Linux-VServer users who run
>>> 100+ installations should be able to figure out on their own that they
>>> should put guest's /tmp into a ramdisk, if a lot of accesses to /tmp
>>> cause performance issues.
>> Perhaps this is a person thing, but I haven't found this issue hard to
>> debug. Checking the state of mounted file systems should be one of the
>> first ports of call when issues arrise. A low size for /tmp means that
>> these issues turn up sooner rather than later, which is much better IMHO.
>> TMPFS is the superior FS for the job.
>> The problem I have had is that clamav doesn't work on Debian with this /tmp
>> size, as it needs space to unpack deffinitions IIRC.
> /tmp was always empty, because after bouncing the message, dovecot removed it
> from there. So there was only a tiny time window when it was full. My mistake
> was not grepping for 'deliver' in maillog (I always grepped for 'postfix',
> and only got that 'code 89' error). Probably others would have found the
> cause more quickly. So.. you've got a point.
> But still I think that less experienced Linux-VServer users (like me) will
> more likely have trouble figuring out why something behaves oddly (and many
> programs behave oddly when they run out of (temporary) disk space) than
> experienced large-scale Linux-VServer users will have setting up tmpfs if
> they think it's necessary.
> I'm convinced that having the entry commented out, together with an
> explanation what it does, would be better for the majority.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Received on Wed May 14 10:21:34 2008