Re: Using TMPFS for /tmp and /var/run?

On 30 March 2012 19:36, Adrian Chadd <adrian_at_freebsd.org> wrote:

> On 30 March 2012 10:56, Chris Rees <crees_at_freebsd.org> wrote:
>> On 30 March 2012 17:31, C. P. Ghost <cpghost_at_cordula.ws> wrote:
>>> On Fri, Mar 30, 2012 at 3:18 PM,  <sthaug_at_nethelp.no> wrote:
>>>>> > However, if you always want to use tmpfs instead of stable storage,
>>>>> please do not.  Some people expect /tmp to be persistent.  This is why
>>>>> /etc/defaults/rc.conf has clear_tmp_enable="NO".  Changing this would break
>>>>> the POLA.
>>>>> >
>>>>> This is a mistake.
>>>>>
>>>>> The default should be clear_tmp_enable="YES"
>>>>> if only to uncover those broken configurations that expect /tmp to be
>>>>> persistent.
>>>>
>>>> If you want to break POLA and make a lot of people angry, sure.
>>>> Otherwise no.
>>>
>>> I couldn't agree more. Not clearing /tmp on reboot has been
>>> the norm for way too long and it is too late to change now.
>>> It's not just POLA, it also involves deleting data of unaware
>>> users, and that should be avoided.
>>>
>>> Anyone willing to change policy w.r.t. /tmp can do so on their
>>> own machines. Nothing is preventing them from doing so.
>>> But by changing defaults, one should err on the side of
>>> caution and remain conservative, IMHO.
>>
>> >From man hier:
>>
>> /tmp/      temporary files that are not guaranteed to persist across
>> system reboots
>>
>> This assumption that people often make 'People will be astonished by
>> this'-- I would like to have someone speak up and actually say "Yes, I
>> use *temporary* directories for long-term storage" rather than the
>> assumption that they are around.
>>
>> Software that assumes this should be fixed, and it won't be until the
>> bug is exposed (I'll look at eaccelerator-- it probably should store
>> its cache in /var/db).
>>
>> Maintaining the status quo because of some hypothetical scenario isn't
>> really productive.
>>
> Let me tell you a story.
>
> Someone decided that ext4 could have a decent speed up if it
> implemented the posix standard for not flushing files on close().
> After all, if you needed it to be guaranteed to be written to disk,
> you would call a flush routine first, before you called close().
>
> So they did this.
>
> Then people testing out ext4 discovered that upon crash, their
> kde/gnome profiles were corrupted.
>
> Why? Because KDE/Gnome authors hadn't ever called flush before
> close(), and they weren't the only ones. They didn't read the
> standard, they only used the system and fixed bugs whenever their
> system behaved against their expectations. They didn't notice that the
> system was being different from the standard.
>
> Guess what ext4 did? :)
>
> Don't mis-estimate POLA.

Well, having thought about what this conversation was *really* about,
I may have unintentionally derailed it a little.

My original intention was to say to Oliver, please, don't be
discouraged from using tmpfs for /tmp, and make sure you send PRs to
the upstream of any programs that misbehave as such.

Let's not make judgement on people who treat /tmp as persistent quite yet ;)

Chris