From Gentoo Wiki
Jump to:navigation Jump to:search
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 01:06, 14 July 2024 (UTC)
:: Your reply ~~~~

Mounting /run

Talk status
This discussion is done as of 2022-02-24.

I always mounted /run manually as tmpfs. But since I updated my kernel from 5.4.48 to 5.4.72 and a @world update, I had multiple issues. LVM was causing warnings at boot, network adapter was not working and as soon as I started Xorg both mouse and keyboard stopped to work. Basically it was breaking udev. After finding this thread bug #737270 I found out it had something to do with my /etc/fstab. But regardless of mode and permission I was not able to fix it unless I commented /run completely out. Without mounting /run manually in /etc/fstab all the issues were fixed instantly. So maybe its better to delete "/run" from Sub-Chapter "Other directories to consider" on this wiki-page to prevent others from running into the same problems. Probably its not possible to mount /run manually in /etc/fstab anymore without breaking udev. — The preceding unsigned comment was added by Severin (talkcontribs)

a possible answer to the tmpfs size and /etc/fstab problem

Talk status
This discussion is still ongoing as of 2022-08-20.

after searching here in the archive I came across the following: so the problem is not new. If you read through the section you will find a possible solution via remount. For example: mount -o remount,size=128m /run

I have created a script for this under /etc/local.d/ and automatically set the tmpfs size during the start. And yes, I use OpenRC. This eliminates the need to use /etc/fstab for /run setup. — The preceding unsigned comment was added by Lloydz (talkcontribs) 20:17, 20 August 2022‎

Why is it "a problem", when /etc/fstab is used? Luttztfz (talk) 19:45, 27 August 2022 (UTC)
I have no idea. people talk about it. in which constellation it becomes a problem I can not say. The easiest way to get around it is the solution described. The cleanest way is to occupy the memory from the outset, which requires the setting option - which is not known. — The preceding unsigned comment was added by Lloydz (talkcontribs) 2022-08-28T15:38:59
Therefore, another example regarding a /etc/local.d/script should be added. Possibly only be pointed out. An example regarding fstab already exists. — The preceding unsigned comment was added by Lloydz‎ (talkcontribs) 2022-09-06T08:07:44‎
Well, according to its documentation, tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap unneeded pages out to swap space.
What this means, in essence, is that all files are in memory until they are swapped out (if ever), whereas without tmpfs the files will be on a mounted filesystem. Assuming that the swap partition is also on the same drive, the only difference when using tmpfs (as apposed to using a filesystem mount) is that the files will only then be stored on the disk when the memory gets filled up.
I'd say that's a win for tmpfs, a gain in speed, lesser wear (e.g. on flash drives like SSDs), an intelligent use of available system memory (RAM) and no harm done in any case.
The maximum size of any tmpfs mount will automatically be half the system RAM, which should be sufficient in any case for /run (and others, like /dev/shm). In other words, the theoretical size is overly big, but this doesn't do any harm even when more than two tmpfs are mounted (taking a theoretical maximum of >100% of the available RAM).
From the Debian Linux man page: /run is required to be a tmpfs on systems supporting tmpfs mounts. And: If desired, the defaults may also be overridden with an entry in in /etc/fstab ...
IMHO a discussion about the (maximum) size of any tmpfs, especially /run and others (like /dev/shm) which actually use only a very limited amount of "disk space" (or rather memory, when using tmpfs), is a non-issue and leads to no result. If you want to change the default 50% of the system RAM for a particular tmpfs mount you can do so in /etc/fstab anyhow, which you should only do if and when you have a very good reason for it.
Luttztfz (talk) 10:57, 6 September 2022 (UTC)