Features/tmp-on-tmpfs

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
Line 22: Line 22:
 
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. Other Unixes, too. Debian's development distribution does the same. ArchLinux defaults to this too. Ubuntu has plans for their 12.10 release.
+
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 ==
By implementing this we generate less IO on disks. This increases SSD lifetime and makes things a bit faster.
+
By implementing this we generate less IO on disks. This increases SSD lifetime,s aves a bit of power and makes things a bit faster.
  
 
/tmp is automatically flushed at boot.
 
/tmp is automatically flushed at boot.
  
Bring Fedora closer to commercial Unixes and other Linux distributions.
+
We bring Fedora closer to commercial Unixes and other Linux distributions.
  
Bring Fedora systems closer to stateless, read-only root by default systems.
+
We make the delta to stateless read-only systems smaller.
  
 
== Scope ==
 
== Scope ==
Line 39: Line 39:
  
 
== How To Test ==
 
== How To Test ==
<!-- 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.  
+
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.
 
+
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.
+
 
+
A good "how to test" should answer these four questions:
+
 
+
0. What special hardware / data / etc. is needed (if any)?
+
1. How do I prepare my system to test this feature? What packages
+
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.
  
 
== 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)? -->
+
None
  
 
== 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. The revert should by fairly trivial and isolated. 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. -->
+
Nothing really.
*
+
  
 
== 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 programms cannot be fixed to usr /var/tmp instead of /tmp for this, there are two options:
<!-- 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". 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:
 +
 
 +
<nowiki>
 +
[Mount]
 +
What=/dev/sda5
 +
Where=/tmp
 +
Type=ext4
 +
</nowiki>
  
 
== 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 -->
+
* See [[Talk:Features/tmp-on-tmpfs]]   
 +
 
 +
A couple of FAQs:
 +
 
 +
'''What about quota on /tmp? tmpfs does not support quota!'''
 +
 
 +
That is true, however no different as with /run or /dev/shm where unprivileged users have 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.
  
 
[[Category:FeaturePageIncomplete]]
 
[[Category:FeaturePageIncomplete]]

Revision as of 18:50, 23 March 2012

Important.png
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
Note.png
All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed

Contents

/tmp on tmpfs

Summary

We'd like to mount a tmpfs on /tmp by default. (Administrators can override this)

Owner

Current status

  • Targeted release: Fedora 18
  • Last updated: 2012-03-22
  • Percentage of completion: 0%

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.

Benefit to Fedora

By implementing this we generate less IO on disks. This increases SSD lifetime,s aves 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.

Scope

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

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.

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.

User Experience

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

Dependencies

None

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. The revert should by fairly trivial and isolated. Just consists of dropping a unit file from the systemd package.

Documentation

Nothing really.

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 programms cannot be fixed to usr /var/tmp instead of /tmp for this, there are two options:

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:

[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 as with /run or /dev/shm where unprivileged users have 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.