On Sun, Apr 15, 2012 at 01:32:52PM +0100, J M Cerqueira Esteves wrote: > According to Roger Leigh <rle...@codelibre.net> > > > The RAMTMP setting only has an effect when there are no fstab > > entries--the fstab entry (if any) will override the RAMTMP setting. > > but it seems /etc/rcS.d/S01mountkernfs.sh actually only lets fstab > override RAMTMP when it has a tmpfs entry for /tmp: > > 1) When root is read-only, RAMTMP is forced to "yes" when there's an > fstab entry, but existence of a fstab entry doesn't force RAMTMP to be "no": > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # If root is read only, default to mounting a tmpfs on /tmp, > # unless one is due to be mounted from fstab. > if [ rw != "$rootmode" ]; then > # If there's an entry in fstab for /tmp (any > # filesystem type, not just tmpfs), then we don't need > # a tmpfs on /tmp by default. > if read_fstab_entry /tmp ; then > : > else > RAMTMP="yes" > fi > fi > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2) After the above, if RAMTMP is "yes" it is only overriden by a fstab > entry with /tmp as tmpfs: > > # Mount /tmp as tmpfs if enabled. > if [ yes = "$RAMTMP" ] || read_fstab_entry /tmp tmpfs; then > domount "$MNTMODE" tmpfs shmfs /tmp tmpfs "-onodev,nosuid$TMP_OPT" > > > In my recently installed Wheezy machine, the end effect is that I have > two /tmp mounts, both with the same size (wondering why the size is the > same... or maybe I failed to understand something)
No, you are correct. There's a deficiency in the logic here. To correct it, I think we should probably use the following logic: RAMTMP FSTAB MOUNT? yes no yes no no no yes tmpfs yes no tmpfs yes (*) yes non-tmpfs no (*) no non-tmpfs no The (*) indicates cases where we currently do the opposite, which need correcting. MOUNT is whether or not we should mount a tmpfs based on the RAMTMP setting and/or any fstab entry which may be present, including both tmpfs and other mounts. We should probably also deal with shmfs and ramfs mounts for completeness. I'm wondering if we should probably also have the same logic for all the other tmpfs mounts as well. I'm currently thinking no, because they are intended to be tmpfses 100% of the time, but there are cases where this does not hold e.g. GNU/Hurd (no tmpfs). But since Hurd is currently not using initscripts, I'm not sure if it's worth doing just to work around a deficiency in hurd. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
