Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow <goswin-v-b@web.de>]

Carlos Alberto Lopez Perez <clopez@igalia.com> writes:

> On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
>> On Fri, 25 May 2012, Thomas Goirand wrote:
>>> for small files, and in that case, it's faster. In reality, it's
>>> not that much faster, thanks to Linux caching of the filesystem,
>> 
>> Under heavy filesystem IO load, yes it is.  By several orders of magnitude.
>> 
> This is a corner case.
>
> Defaults should be sane for most of the cases, and not for corner cases.
> Also defaults should prioritize stability (and non-breakage) over
> performance.
>
> With "tmpfs on /tmp" you are breaking many applications that assume that
> they have enough space to write on /tmp like the flash player ( see
> Debian bug #666096 ) or cdrecord software ( see #665634 ).

And again, tmpfs isn't breaking it, only the size of /tmp. A 1GB real
/tmp filesystem breaks them just like a 1GB tmpfs breaks them.

So make /tmp large enough. Improve the heuristic that defines the size
for tmp.

> The FHS [2] does not define *nothing* about the size of /tmp or
> /var/tmp. It *only* says that programs using files under /tmp must not
> assume that this files are preserved between invocations of the program
>
>
> So please, *stop* saying that /tmp should be only for small files
> because this is simply *not* *true*. It is *not* defined on any standard
> that files on /tmp should be small. Period.

It is also *not* defined on any standard that files on /tmp may be
big. Period.

Sorry, that argument simply cuts both ways.

An application that stores files in /tmp without checking size and/or
handling ENOSPC properly is just broken and needs to be fixed
regardless.

MfG
        Goswin