[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: