[HEADS-UP] Rawhide: /tmp is now on tmpfs

[Brian Wheeler]

On 07/13/2012 10:14 AM, Dennis Jacobfeuerborn wrote:
> On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
>> On 07/12/2012 09:54 PM, Harald Hoyer wrote:
>>
>>> Again.. tmpfs is restricted to half the RAM size by default. You can't
>>> store 8-9GB of trash.. only 2GB, which might land on swap over time.
>> As I have already pointed out some time ago, isn't a bizarre situation
>> that as an application developer I can either use malloc() and store things
>> up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
>> things up to RAM/2 (lets' say 4/2=2GB)?
>>
>> Once upon a time you used to use files to go *beyond* RAM limits.
>>
>> And the answer to this objection is....? move to /var/tmp.
>> So patch everything (and good luck with closed source stuff).
> An application (closed source or not) that plans to store non-trivial
> amounts of data somewhere should have a mechanism/config option to let the
> user specify where to store that data. Simply hoping that you can dump X
> gigabytes of data in some hard-coded place is not a good idea.

Sure, its not a good idea, but its been done for decades...successfully.

>> Wouldn't have been more reasonable to create a /ramtmp and patch
>> the applications? (this would have just been "patched for speed", not
>> "patched for correctness" as the sort case).
>> Hey, wait, we already have /dev/shm. So we just had to patch
>> the applications (if anyone cares).
> That way *every* application would have to be patched. Using /var/tmp is
> only required for a small number of apps that actually have more specific
> needs regarding the data they intend to put there.

And right here is the problem.  The "more specific need" is now based on 
size of the data relative to the amount of memory in the machine.   
That's just messed up.

Does anaconda on F18 put /home and / on different volumes?  I did a 
rawhide install using the F17 and all defaults and they're combined.  
Under this scenario I have sizeof(rootfs) - 5G of disk I can potentially 
use for /tmp.  Under the tmpfs scheme I have 1G (this is a 2G VM) .  The 
answer is, of course, to use /var/tmp -- which only moved the "problem" 
and didn't do squat except to generate a bunch of patches which amounted 
to s|/tmp|/var/tmp|g

To make this a default was a dumb decision which has never been 
adequately justified.  I did finally see some performance numbers for a 
software build, but that isn't the general case and I can't believe the 
benefits touted even impact the general case, especially given the size 
limitations of /tmp.