Carlos Alberto Lopez Perez <clo...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hauvmgwm.fsf@frosties.localnet
