Bug 14376 - fstab should set tmpfs to 25%
Summary: fstab should set tmpfs to 25%
Status: RESOLVED WONTFIX
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 3.4
Assignee: David Turgeon
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2021-05-03 19:13 UTC by David Turgeon
Modified: 2021-05-13 15:34 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Turgeon 2021-05-03 19:13:57 UTC
In 
https://git.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873

/run was added as a tmpfs but the size= field was left empty in the fstab file

Reading man page it appears it could be set to size=25%
which seems like a better option when using two tmpfs by default
Comment 1 Randy MacLeod 2021-05-06 14:54:00 UTC
Can you provide a link to the man page and or quote it?

The concern is that the default shared pool of RAM for tmpfs is up to 50%, is that a problem and if so why?
Comment 2 David Turgeon 2021-05-07 01:53:22 UTC
https://linux.die.net/man/8/mount

Override default maximum size of the filesystem. The size is given in bytes, and rounded up to entire pages. The default is half of the memory. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your physical RAM: the default, when neither size nor nr_blocks is specified, is size=50%
Comment 3 David Turgeon 2021-05-08 14:45:48 UTC
I couldn't find anywhere in documentation saying this was shared.  So I tried filling up both tmpfs and it showed that processes started to get killed by OOM.  I never actually was able to fill both partitions before the system became inaccessible...
Comment 4 Joshua Watt 2021-05-11 18:55:47 UTC
Fair enough. However, I suspect it might cause problems with existing users to suddenly put a hard limit that is half what it used to be, so I think we need to leave this
Comment 5 Joshua Watt 2021-05-13 15:34:34 UTC
There are use cases where users write large files to the tmpfs with the understanding that they have "enough ram" to handle it (I know of several places that I'm doing the personally). For better or worse, lowering the default priority will break these use cases, so we shouldn't change it.