On Wed, Apr 13, 2011 at 01:23:04PM +0200, Adam Borowski wrote: > On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote: > > On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl <biebl@debian.org> wrote: > > > I don't think symlinking /tmp to /run would be a good idea, as one could fill up > > > /tmp (accidentaly) pretty quick. > > > If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea > > > to me. > > > > While were about this, for installs where the users select multiple > > partitions we currently create a separate /tmp partition. > > > > This strikes me as suboptimal, since one could use the disk space > > allocated to /tmp as extra swap and then allocate a tmpfs of that size > > to be mounted on /tmp with no effect other than allowing the system to > > have access to more swap than it would have otherwise had (of course, > > that's probably more than it needs, so instead you could just save some > > disk space that would otherwise be left generally unused by overloading > > the swap usage with /tmp usage. > > > > Therefore, in the multi-partition setup, I think we should also default > > to having /tmp on tmpfs. > > Sounds like a great idea. I'd extend it to any setups with a swap. > > Tmpfs is a lot faster than regular filesystems: it doesn't have to care > about preserving the data's integrity after a crash and thus has no > barriers, journaling, fsync(). When there's plenty of unused memory, the > data will not ever touch the disk, too -- gracefully getting written out > when there is a better use for memory it takes. Since most files in /tmp/ > are very short lived, it's a good optimization. I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb Note that it is safe to test these out on live systems; I've installed it on my amd64 and powerpc machines, and not had any issues. I did notice an unclean umount of /var in one case, but I think this was due to messing around with mount --move which messes up /etc/mtab when moving recursively (/run/lock probably didn't get unmounted). I've not seen that on any other systems. So, by default, you get (separate tmpfs mounts): /run /run/shm /lib/init/rw (RAMLOCK=no, RAMSHM=yes, RAMTMP=no) For additional safety and security, it's possible to mount everything as separate tmpfs filesystems: /run /run/shm /run/lock /lib/init/rw /tmp (RAMLOCK=yes, RAMSHM=yes, RAMTMP=yes). This lets one have separate size limits and mount modes for each mount. Alternatively, it's possible to have everything on a single /run tmpfs, including /tmp (excluding /lib/init/rw, which will be removed soon): /run /lib/init/rw /tmp → /run/tmp (RAMLOCK=no, RAMSHM=no, RAMTMP=no). Note that /tmp was symlinked to /run/tmp prior to restarting, and /run/tmp was created by the init scripts (mountkernfs). The symlink needs creating by hand should you wish to do this. Having /tmp as a symlink can be used whatever the setting of RAMTMP, so you could have a tmpfs mounted on /run/tmp if you chose. In all these cases, these links were automatically created: /dev/shm → /run/shm /var/run → /run /var/lock → /run/lock The default size and permissions were set as proposed earlier in this thread; there's still time to adjust or remove those depending upon what the general consensus is. We could also make not mounting /run/shm the default, so that it's shared with /run by default; users who need a dedicated large /run/shm could then enable this at their discretion using RAMSHM and SHM_SIZE. I would be very grateful to anyone who can take the time to install the new initscripts and try it out. It should set up bind mounts of /var/run, /var/lock and /dev/shm to their locations in /run on installation, and then set up the tmpfs filesystems properly and do the conversion to symlinks on reboot. Note that I did discuss doing this migration all in postinst using mount --move with mbiebl, but it's unfortuntately linux-specific and has some race conditions between moving and setting up the symlinks (which may or may not be acceptable). This patch errs on the side of caution and ensures that the directories being moved are available at all times, and that the code works on all architectures. Also note that the move of /dev/shm to /run/shm might require the selinux stuff tweaking. This might require a change in one of the selinux packages. But I know little about selinux. One oddity I noticed was that /etc/default/rcS is not a conffile, making it difficult to add new options on upgrade since it's only copied once on initial install. Does anyone know why this is the case, and would it be a problem if I made it into a conffile in order to add the new RAMSHM and RAMTMP options (and remove RAMRUN)? I've worked around this by setting defaults if unset in /lib/init/vars.sh, but it might be nice to be able to update the configuration as well so the current options are visible to the admin. So other than choosing sensible defaults for /etc/default/rcS and /etc/default/tmpfs, I think this is ready to be deployed. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature