(Moved to FeatureReadyForFesco, ticket #834)
|Line 109:||Line 109:|
* See [[Talk:Features/tmp-on-tmpfs]]
* See [[Talk:Features/tmp-on-tmpfs]]
Revision as of 19:27, 30 March 2012
/tmp on tmpfs
We'd like to mount a tmpfs on /tmp by default. (Administrators can override this)
- Name: Lennart Poettering
- Email: lennart at poettering dot net
- Name: Kay Sievers
- Email: kay at redhat com
- Targeted release: Fedora 18
- Last updated: 2012-03-28
- Percentage of completion: 10%
We'd like to mount a tmpfs on /tmp by default, but still allow administrators to opt out from this.
Solaris has been doing this since 1994. (Much like other Unixes, too.) Debian's next release defaults to tmpfs on /tmp, too. ArchLinux defaults to this as well. Ubuntu has plans for their 12.10 release.
Benefit to Fedora
By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
/tmp is automatically flushed at boot.
We bring Fedora closer to commercial Unixes and other Linux distributions.
We make the delta to stateless read-only systems smaller.
systemd upstream needs a minimal change to ship a mount unit for /tmp by default. (Upstream already made this change)
We might need to patch a couple of packages not to store big files and files needing boot persistance in /tmp, but rather in /var/tmp. This work has already progressed due to Debian's work.
Programs should follow the rule: if you are privileged, place it in /run/<your-program-name>/. Otherwise, if it's large or needs persistancy across reboots, place it in /var/tmp. Otherwise place it in /tmp. For a longer explanation see this blog story.
The distinction of /tmp vs. /var/tmp regarding the lifetime and storage capacity is well established in most commercial Unixes.
How To Test
The system should boot up and work as normal. Applications should work as normal. However, /bin/mount should show /tmp to be a tmpfs. Besides that the system operates normally and a check that /tmp is actually a tmpfs there is little to test.
The user experience should barely change. This is mostly a low-level change that has little visibility to the user.
Possibly a few other packages need to be updated to move their temporary files from /tmp into /var/tmp. We are not aware of any in particular where this is necessary, but we expect we might encounter a small number as we turn this feature on in F18.
We'll create a tracker bug and add all relevant bugs in the various packages to it as they show up.
The plan is like this:
Turn on /tmp as tmpfs very early in the Fedora 18 cycle. Fix any problems coming up, and revert back to non-tmpfs /tmp if they become too many. Programs that are fixed should stay how they are, their changes need not to be reverted.
The reverting (if necessary) should by fairly trivial and isolated. It just consists of dropping a unit file from the systemd package.
/tmp now defaults to tmpfs. This might break a few programs which assume that they can place large files in /tmp or that /tmp is persistant across boot. If these programs cannot be fixed to use /var/tmp instead of /tmp for this, there are two options to undo the /tmp-on-tmpfs change locally:
Disable mounting of tmpfs on /tmp by issuing "systemctl mask tmp.mount". Note that this will entirely disable any mounting of any file system to /tmp.
To mount a different file system to this place instead place a configuration file like this in /etc/systemd/system/tmp.mount which will then override the vendor default in /etc/systemd/system/tmp.mount:
[Mount] What=/dev/sda5 Where=/tmp Type=ext4
Comments and Discussion
A couple of FAQs:
What about quota on /tmp? tmpfs does not support quota!
That is true, however no different than with /run or /dev/shm where unprivileged users have write access, too. The quota on tmpfs problem needs to be fixed in the kernel anyway; whether it is 2 or 3 file systems that are writable by normal users makes little difference.
My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs!
The application should be fixed to use /var/tmp.
My application writes temporary files to /tmp and they are gone after a reboot!
The application should be fixed to use /var/tmp. FHS recommends that /tmp is flushed on reboot, and that's what we do here.
My application writes huge downloaded files to /tmp, and this breaks on tmpfs!
The application should be fixed to use XDG user-dir's Download directory, as exposed in GLib's g_get_user_special_dir(G_USER_DIRECTORY_DOWNLOAD)
I don't want to use tmpfs for my /tmp
See the "Release Notes" section above for hints how to turn this off. This is just a default, and is overridable.
Why is this mount established via a systemd unit file, instead of an entry in /etc/fstab?
We believe that /etc/fstab is the place to configure real file systems, for actual user data, backed by real devices. The API file system /tmp does not qualify for that in our eyes. /tmp is very much something that should just exist as part of the OS and needs no user configuration. It is our goal to allow systems to boot up fully functional with an (almost) empty /etc/fstab. Also it is much easier to enable this logic for existing installs without the need to patch /etc/fstab. This is especially the case since making code that patches /etc/fstab like this idempotent is very hard since the user could just remove the entry we patched in and we couldn't distuingish this case from the not-yet-patched case.
Why is this mount established via a systemd unit file, instead of a built-in mount or one already established in the initrd?
We want to allow the administrator to disable the tmpfs mount or replace it with something else. This is very hard to accomplish if we mount that directory with built-in code or already in the initrd. Also, it's a good idea to keep the built-in mounts minimal, and since /tmp files are primarily a utility for user code (system code should instead use files in private directories in /run), there's no need to mount this before user code is executed.
What happens with my old /tmp directory as soon as this feature is enabled?
On the next boot we'll simply mount the directory over with a tmpfs.