Re: /tmp as tmpfs and consequence for imaging software
Richard <richard.bown@blueyonder.co.uk> writes:
> On Wed, 16 Nov 2011 13:21:47 +0100
> Didier Raboud <odyx@debian.org> wrote:
>
>> Salvo Tomaselli wrote:
>>
>> >> I think the problems you describe are quite uncommon. Yes, there are use
>> >> cases where tmpfs for /tmp isn't the best solution but I think most
>> >> people do not place 1.2GB files in their /tmp and benefit greatly from
>> >> tmpfs.
>> >
>> > I thought DVD burners were quite common... and almost every desktop or
>> > laptop has one. And a DVD is 4GiB when not 7. And usually burning software
>> > lets you decide if you want to 1st create an iso and then burn it.
>>
>> Given that any burning software can (approximately) determine what size the
>> ISO file will be, it should really not start to write it in /tmp when the
>> /tmp size is not big enough (which the software can also check). Prompting a
>> user with "I will not be able to write ${file} in /tmp, please point me to a
>> location where I can." should not be too much of a problem.
>>
>>
>>
>
> Hi would the real solution be to make /tmp dynamic ?, that would allow for dual layer burning and
> blueray, or is that easier said than done.
You can make /tmp any size on the fly. But you need to have enough SWAP
setup to actualy use it. And that usualy needs some planing ahead.
> The other area where a large /tmp is needed is video streaming, especially if you are generating a
> video and putting down a USB port for external encoding to DVB-T or DVB-S., but that's a specialised
> application.
Again a case where you would not want /tmp to be on your / filesystem
where free space gets quickly fragmented. So if you don't have a
seperate /tmp filesystem you have already a suboptimal configuration and
having tmpfs for /tmp just makes that more noticeable.
MfG
Goswin
Reply to: