/tmp on tmpfs

[Marcela Mašláňová]

On 04/06/2012 02:58 PM, Ralf Corsepius wrote:
> On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
>> On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
>>> On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
>>>> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>>>>> * #834 F18 Feature: /tmp on tmpfs -
>>>>> http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
>>>>> * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
>>>>
>>>> Actually I think this is a good feature, but ...
>>>>
>>>> The feature page is wrong about "The user experience should barely
>>>> change. This is mostly a low-level change that has little visibility
>>>> to the user."
>>>>
>>>> tmpfs is different in a number of important ways:
>>>>
>>>> - it's very limited in space compared to a real disk
>>> This is the reason why I refused having /tmp as tmpfs (or even as a
>>> separate partition) few months ago. Has anybody tried to use e.g.
>>> Brasero with it? Well, if you are burning a DVD, Brasero needs about 4
>>> GB on /tmp -- not enough space in RAM or wasting a lot of disk space on
>>> having such big /tmp partition that is most of the time unused. Yes, you
>>> can tell Brasero to use some other space, but it obviously relies on
>>> volatility of the /tmp and doesn't clean after itself. I'm quite sure
>>> this is not only the case of Brasero.
>>>
>>
>> We should file bugs on those issues and add them to some tracker bug,
>> which will be created for tmpfs related issues.
> That a lost fight, because one of /tmp's primary purposes is to
> temporarily store almost arbitrarily huge amounts of data, instead of
> storing them in memory.
>
> This would mean, to prepare tmpfs for this use-case, you'd have to make
> swap similarly large as /tmp is without tmpfs.
>
>> Brasero, k3b and
>> applications for scanning will probably need patches.
>
> No idea, what you are intending to do. These apps use huge amounts of
> temporary data. Amounts of data, its devs probably considered to be too
> big to be stored in memory and thus decided to store them in /tmp.
> A fully legitimate use case.
>
> Also consider that the required size of data in /tmp can very dynamic
> and be very different in different use-cases. This is a fact people
> often do not notice causes unexpected surprises to them (e.g. when
> launching some heavy-weight compile job).
>
>  > I hope some of these bugs were fixed,
> Are you seriously calling storing temporary files into /tmp to be bugs?
>
> Ralf

I tried to explain position of FESCo, but I'd rather leave it to someone 
who likes this change ;-)

Marcela