Features/tmp-on-tmpfs

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Created page with " {{admon/important | Set a Page Watch| Make sure you click ''watch'' on your new page so that you are notified of changes to it by others, including the Feature Wrangler}} {{adm...")
 
(User Experience)
 
(44 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
{{admon/important | Set a Page Watch| Make sure you click ''watch'' on your new page so that you are notified of changes to it by others, including the Feature Wrangler}}
 
 
{{admon/note | All sections of this template are required for review by FESCo.  If any sections are empty it will not be reviewed }}
 
 
 
= /tmp on tmpfs =
 
= /tmp on tmpfs =
  
 
== Summary ==
 
== Summary ==
We'd like to mount a tmpfs on /tmp by default. (Administrators can override this)
+
Mount a tmpfs on /tmp by default. (Administrators can override this)
  
 
== Owner ==
 
== Owner ==
Line 13: Line 8:
 
* Email: lennart at poettering dot net
 
* Email: lennart at poettering dot net
 
* Name: [[User:Kay| Kay Sievers]]
 
* Name: [[User:Kay| Kay Sievers]]
* Email: lennart at poettering dot net
+
* Email: kay at redhat com
  
 
== Current status ==
 
== Current status ==
 
* Targeted release: [[Releases/18 | Fedora 18 ]]  
 
* Targeted release: [[Releases/18 | Fedora 18 ]]  
* Last updated: 2012-03-22
+
* Last updated: 2012-05-29
* Percentage of completion: 0%
+
* Percentage of completion: 100%
  
 
== Detailed Description ==
 
== Detailed Description ==
 
We'd like to mount a tmpfs on /tmp by default, but still allow administrators to opt out from this.
 
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. Debian's development distribution does the same. Ubuntu has plans, too.
+
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 ==
 
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
+
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 clean on every boot
 +
 
 +
We bring Fedora closer to commercial Unixes and other Linux distributions.
 +
 
 +
We make the delta to stateless read-only systems smaller.
  
 
== Scope ==
 
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+
systemd upstream needs a minimal change to ship a mount unit for /tmp by default. (DONE)
  
== How To Test ==
+
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.
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
+
  
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
+
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 [http://0pointer.de/blog/projects/tmp.html this blog story].
  
A good "how to test" should answer these four questions:
+
The distinction of /tmp vs. /var/tmp regarding the lifetime and storage capacity is well established in most commercial Unixes.
  
0. What special hardware / data / etc. is needed (if any)?
+
== How To Test ==
1. How do I prepare my system to test this feature? What packages
+
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.
need to be installed, config files edited, etc.?
+
2. What specific actions do I perform to check that the feature is
+
working like it's supposed to?
+
3. What are the expected results of those actions?
+
-->
+
  
 
== User Experience ==
 
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
+
The user experience should barely change. This is mostly a low-level change that has little visibility to the user.
 +
 
 +
 
 +
Loss of information in /tmp when the system shuts down (for reboot or for power off) may affect people who are used to the current behavior of files persisting until they've not been touched for ten days.
 +
 
 +
This may also impact analysis of system crashes as /tmp will be lost on a non-clean shutdown as well as an orderly one.
 +
 
 +
 
 +
Large files in /tmp may suddenly become more problematic.
  
 
== Dependencies ==
 
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
+
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. (DONE: https://bugzilla.redhat.com/show_bug.cgi?id=826015)
 +
 
 +
We'll announce this on fedora-devel when we turn this on (with references to documentation), to ensure everybody is aware, and informed. (DONE)
  
 
== Contingency Plan ==
 
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->
+
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.
  
 
== Documentation ==
 
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
+
Change in persistance behavior needs to be documented.
*
+
  
 
== Release Notes ==
 
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
+
/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:
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
+
 
*
+
* Disable mounting of tmpfs on /tmp by issuing "systemctl mask tmp.mount", and reboot. Note that this will entirely disable any mounting of any file system to /tmp. /tmp will hence reside on the root fs if this is done. (Undo with "systemctl unmask tmp.mount")
 +
 
 +
* To mount a different file system (instead of tmpfs) to this place simply edit /etc/fstab, and add an entry for it there, it will take precedence over our new distro default. Also, reboot.
 +
 
 +
Also, many programs understand the $TMPDIR variable, which can be used to redirect the temporary directory for a one specific program invocation to a different directory. Use this on the shell like this:
 +
 
 +
  $ mkdir -p $HOME/waldo
 +
$ TMPDIR=$HOME/waldo foobar
 +
 
 +
This will execute "foobar" with the temporary directory set to $HOME/waldo. Note that not all applications support $TMPDIR.
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
* See [[Talk:Features/YourFeatureName]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
 
  
 +
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 user downloads 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.
 +
 +
Note that /etc/fstab takes precedence over the systemd unit file. Systems which mount a specific file system to /tmp hence will continue to work as always. Only systems with /tmp on the root fs will be updated to get tmpfs by default.
 +
 +
'''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.
 +
 +
* See [[Talk:Features/tmp-on-tmpfs]] 
  
[[Category:FeaturePageIncomplete]]
+
[[Category:FeatureAcceptedF18]]
<!-- When your feature page is completed and ready for review -->
+
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
+
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
+
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
+

Latest revision as of 13:55, 1 June 2012

Contents

[edit] /tmp on tmpfs

[edit] Summary

Mount a tmpfs on /tmp by default. (Administrators can override this)

[edit] Owner

[edit] Current status

  • Targeted release: Fedora 18
  • Last updated: 2012-05-29
  • Percentage of completion: 100%

[edit] Detailed Description

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.

[edit] 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 clean on every boot

We bring Fedora closer to commercial Unixes and other Linux distributions.

We make the delta to stateless read-only systems smaller.

[edit] Scope

systemd upstream needs a minimal change to ship a mount unit for /tmp by default. (DONE)

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.

[edit] 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.

[edit] User Experience

The user experience should barely change. This is mostly a low-level change that has little visibility to the user.


Loss of information in /tmp when the system shuts down (for reboot or for power off) may affect people who are used to the current behavior of files persisting until they've not been touched for ten days.

This may also impact analysis of system crashes as /tmp will be lost on a non-clean shutdown as well as an orderly one.


Large files in /tmp may suddenly become more problematic.

[edit] Dependencies

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. (DONE: https://bugzilla.redhat.com/show_bug.cgi?id=826015)

We'll announce this on fedora-devel when we turn this on (with references to documentation), to ensure everybody is aware, and informed. (DONE)

[edit] Contingency Plan

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.

[edit] Documentation

Change in persistance behavior needs to be documented.

[edit] Release Notes

/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", and reboot. Note that this will entirely disable any mounting of any file system to /tmp. /tmp will hence reside on the root fs if this is done. (Undo with "systemctl unmask tmp.mount")
  • To mount a different file system (instead of tmpfs) to this place simply edit /etc/fstab, and add an entry for it there, it will take precedence over our new distro default. Also, reboot.

Also, many programs understand the $TMPDIR variable, which can be used to redirect the temporary directory for a one specific program invocation to a different directory. Use this on the shell like this:

$ mkdir -p $HOME/waldo
$ TMPDIR=$HOME/waldo foobar

This will execute "foobar" with the temporary directory set to $HOME/waldo. Note that not all applications support $TMPDIR.

[edit] 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 user downloads 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.

Note that /etc/fstab takes precedence over the systemd unit file. Systems which mount a specific file system to /tmp hence will continue to work as always. Only systems with /tmp on the root fs will be updated to get tmpfs by default.

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.