Re: Moving /tmp to tmpfs makes it useless
Carlos Alberto Lopez Perez <firstname.lastname@example.org> 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
> 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
> The FHS  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
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