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

[Brian Wheeler]

On 05/31/2012 08:59 AM, Lennart Poettering wrote:
> On Thu, 31.05.12 08:51, Matthew Miller (mattdm at mattdm.org) wrote:
>
>> On Thu, May 31, 2012 at 12:55:28PM +0200, Ralf Corsepius wrote:
>>>> Now /var/tmp should be "more persistent" which we don't need,
>>> Correct, using /var/tmp is wrong and a mistake.
>>>
>>> IMO, advising people to modify their code to using /var/tmp instead of /tmp
>>> is absurd and evidence of ignorance towards traditional use of /tmp and the
>>> FHS.
>> Well, not just FHS, but "traditional" usage within Red Hat and Fedora. For
>> as long as I can remember, /tmp has had a 10-day retention and /var/tmp
>> 30-day.
>>
>> Does that matter?
> We still have 10d and 30d clean-up for that. With one addition though:
> /tmp is also flushed on reboot.
>
> Lennart
>

I'm still unsure what the point of this "feature" really is.

The wiki page lists the features as:

* By implementing this we, by default, generate less IO on disks. This 
increases SSD lifetime, saves a bit of power and makes things a bit faster.

Do we have actual numbers for this?  It would seem like we already have 
this with ext4's deferred allocation and the pagecache.

* /tmp is automatically flushed at boot.

It seems like adding an rm to the startup sequence would do this with 
less surprises.


* We bring Fedora closer to commercial Unixes and other Linux 
distributions.

Um, so?  Any solaris admin worth their salt kills the ram-based /tmp as 
soon as the install is finished.  Its been that way since the 90's.

* We make the delta to stateless read-only systems smaller.

Why is this a win for the normal user?


The page says the user experience should barely change -- which I think 
is really downplaying the scope of this change.

Firstly, the cleanup of /tmp on reboot is a behavior change that is 
going to bite a lot of people, no matter how bold and large it appears 
in the release notes.  This isn't terribly controversial, but it still 
sucks for those who get hit by it.

More importantly, the restriction that /tmp be used for files that are 
less than an installation-defined size is going to cause a lot of 
problems.  Patching everything to use /var/tmp because we don't know how 
big the data file is going to be in advance just moves the problem 
somewhere else and doesn't solve anything.  There are going to be 
mystery "disk full" messages and issues on low memory machines.

So why are we doing this again?  How is this a benefit to the normal user?

At the most, this should be an opt-in feature rather than the default.

Brian