/tmp on tmpfs

[Ralf Corsepius]

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