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

[Nicholas Miell]

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.

> I think the fact that we get less disks accesses (just think noatime and
> stuff for the files dropped there) is more interesting than using the
> absolute minimal amount of memory.

They're already on a relatime mount, and don't bind mounts support
noatime now? (e.g. mount --bind /var/run /var/run; mount -o
remount,noatime /var/run)

>> I know that dentries and inodes for regular filesystems can be discarded
>> from RAM if they're not in use, is that the case for a tmpfs?
>> How often are the files in /var/run and /var/lock accessed? Is the
>> kernel likely to discard them?
> 
> Note that under memory pressure tmpfs can be swapped out.

The data pages can, but the inodes and dentries are permanently pinned
in unswappable kernel memory.

>> Files in /var/run tend to be 4 or 5 bytes in length, does that mean they
>> each use an entire page of RAM or swap? There are vastly fewer swap
>> pages than there are filesystem blocks, isn't this less efficient?
> 
> Yes, normal files will take up 4k if they contain data. But that's
> something that could be fixed and which would not only be useful for
> this usecase but the much heavier existing users of tmpfs such as udev.

That's a hypothetical future feature, which isn't exactly relevant to
the issue at hand. (And I think mmap() would make that really
complicated.) If anything, it's an argument that udev should be moved
off of a tmpfs, but that's another discussion entirely.