14376 2021-05-03 19:13:57 +0000 fstab should set tmpfs to 25% 2021-05-13 15:34:34 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED WONTFIX Medium normal 3.4 1 david.turgeon david.turgeon JPEWhacker meta.mr.watcher meta.watcher randy.macleod --- --- Don't know oldest_to_newest 90233 0 david.turgeon 2021-05-03 19:13:57 +0000 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 90282 1 randy.macleod 2021-05-06 14:54:00 +0000 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? 90313 2 david.turgeon 2021-05-07 01:53:22 +0000 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% 90322 3 david.turgeon 2021-05-08 14:45:48 +0000 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... 90345 4 JPEWhacker 2021-05-11 18:55:47 +0000 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 90378 5 JPEWhacker 2021-05-13 15:34:34 +0000 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.