Bug#692559: Debian-init-diversity Digest, Vol 3, Issue 63
Roger Leigh
rleigh at codelibre.net
Sat Dec 29 20:12:56 GMT 2018
On 29/12/2018 18:36,
debian-init-diversity-request at chiark.greenend.org.uk wrote:
> Regarding RAMTMP, I am not sure whether it is actually useful. Really,
> if you want /tmp in tmpfs, just add entry into /etc/fstab. There should
> be one, and only one oblivious way to do it.
RAMTMP was added primarily for completeness. If you read mount_tmp in
mount-functions, you'll see that there are circumstances where we
override it under certain conditions, e.g. read-only root fs or lack of
space on root fs. These mitigations are intended to allow booting on a
system which would otherwise be broken due to the lack of a functional /tmp.
In general, the tmpfs handling in the initscripts was deliberately
intended to allow direct configuration in /etc/fstab, which takes
precedence over the /etc/default/tmpfs settings. The reason for the
default settings was to expose some of the variables used in the scripts
which were useful to configure all of the standard tmpfs filesystems.
This includes all the size limits. Unlike for fstab (which does allow
absolute size or percentage), here you can compute the limits on the fly
based upon the system memory and whatever other factors you desire.
It's not expected that this will be commonly used, but it's there for
those that wish to safely use multiple tmpfs filesystems with strict and
intelligently-set limits, with no chance of OOMing the system by
accident or malicious intent.
Regards,
Roger
More information about the Debian-init-diversity
mailing list