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.
> >Patrick.
>
> 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.
Patrick.
-- STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/ Phone: +86 (21) 5427 7799 x 826 Fax: +86 (21) 6485 0071 PGP key: https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005