[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

Callum Lerwick seg at haxxed.com
Wed Nov 24 19:08:36 UTC 2010


On Tue, Nov 23, 2010 at 5:15 PM, Nicholas Miell <nmiell at gmail.com> wrote:
> On 11/23/2010 02:54 PM, Lennart Poettering wrote:
>> On Tue, 23.11.10 13:41, Nicholas Miell (nmiell at gmail.com) wrote:
>>> On 11/23/2010 12:48 PM, Lennart Poettering wrote:
>>>> Heya!
>>>>
>>>> I hereby want to let everybody know that in the next days I will turn on
>>>> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
>>>> with the following accepted F15 feature:
>>>>
>>>> https://fedoraproject.org/wiki/Features/var-run-tmpfs
>>>>
>>>
>>> Is this actually an improvement?
>>
>> See the spec page.
>
> The spec page says it'll be better, but is very vague as to why.
>
> Basically, I'm looking for a "Doing this will keep $X kilobytes
> permanently pinned in RAM (in the form of dentry and inode structs) and
> $Y bytes in RAM or swap (in the form of file data pages), of which $Z
> bytes is wasted (due to the fixed page size) and this is {worth it, not
> worth it} due to the $N millisecond improvement in boot times."
>
> i.e. an acknowledgment that somebody thought about the trade-offs and
> decided it is the right thing to do.

How about "Less un-necessary crap scribbled all over the filesystem"?
In an age of Live CD/DVD/USB, and flash-based storage devices, cheap
and free filesystem writes can no longer be taken for granted. Its
amazing how much state is spread around the filesystem. Persistent
network rules in /etc/udev/rules.d/, and dhcp client state in
/var/lib/dhclient/ are just a few examples of what has caused me
endless trouble swapping a HD between a few different systems while I
evaluate which works best as a MythTV system. I end up having to clear
the persistent net rules, the client-side lease state, AND the lease
in my router just to get a different motherboard to take the same
fixed IP address lease on eth0. (Which MythTV gets angry if it doesn't
have) State, state saved everywhere...

In an age where "Live" systems are a major use case, why are we saving
all this random state all over that necessitates complexity like
filesystem overlays (how much ram does THAT all eat on a running Live
system?) when its all just going to get tossed out anyway?


More information about the devel mailing list