Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm thinking of having /tmp on its own partition... what would be a good filesystem to format it with?

The reason I ask is because the data being stored in /tmp is not permanent, so I don't need journaling, a fancy index, or anything.

share|improve this question
add comment

8 Answers

up vote 23 down vote accepted

I sometimes find moving /tmp to ram (tmpfs) is the best solution (Especially on my setups which use a lot of disk intensive IO stuff - MySQL, etc) if you have enough RAM to feed it.

share|improve this answer
2  
I have 2GB of RAM, so that's probably not an option. –  Nathan Osman Aug 8 '10 at 3:30
2  
Actually this should be plenty of RAM. /tmp usually isn't used that much with normal usage of your system (whatever that is). –  joschi Aug 8 '10 at 6:00
3  
tmpfs will use swap if it needs to - so your swap space can do double duty as /tmp, no need to allocate extra space. –  gbroiles Aug 8 '10 at 6:27
    
@George How big would you intend to make your /tmp partition? –  Marco Ceppi Aug 8 '10 at 14:43
1  
@George that's a plenty big enough partition size for /tmp - on my desktop I at best use 12MB, though on my servers /tmp can get crazy big when customers do stupid things in MySQL and scripting languages that cause /tmp to get a lot bigger. The brilliant thing with tmpfs is it won't just take 64MB of ram away that's just a hard ceiling. tmpfs will scale as more space is needed - so you only consume in tmpfs what is needed at that time. –  Marco Ceppi Aug 8 '10 at 15:59
show 2 more comments

There are several good choices here:

  1. tmpfs: is a filesystem which stores its files in RAM. This doesn't mean that the filesystem will eat all your RAM. Instead it takes only that amount it really needs. Usually only some MB are needed. If you'll use it, add a line like: none /tmp tmpfs size=64M,mode=1777 0 0 to your /etc/fstab. You can change the size to a value you like. If you think at some point that it is too less, you can use mount to increase the size: mount -t tmpfs tmpfs /tmp -o size=128M,mode=1777,remount. The size will be increased in place without deleting existing files.
  2. ext2/3: You said in your question that you don't need any fancy features. However I would advice for using a journal. Because if you use ext2 and you have a quite large /tmp it would take some time for checking it. ext3 boots any many cases faster. Therefore I would suggest the use of journalling.
  3. ext4, reiserfs etc.: Some software uses /tmp for storing large amounts of small files. So in some cases there are no more free blocks and the filesystem is full. ext4 and also reiserfs store files in a different way. So it could be a good choice to use those for your /tmp.

If your computer runs for a long time, it is a good idea to delete unused files in /tmp. tmpreaper is one solution which does that for you.

However my first choice would be using tmpfs.

share|improve this answer
add comment

Using tmpfs should be fine for your needs, provided that you have adequate RAM installed.

That being said...something that should be considered with regard to using a ramdisk for /tmp (this taken from an older post elsewhere):

  • Should /tmp be on a real disk area or allowed to be implemented basically on the SWAP area (or tmpfs)?

When it's heavily used, this is a temptation - "we'll put /tmp into a RAM disk, it'll speed up access, and when the system reboots/shuts down, there's nothing to clean up". However, if you are thinking of implementing temp space as a RAM disk that will be swapped, then I would consider the ramifications of your system's swap space usage by other programs. If swap is there as a form of "emergency overflow" for when the system is in dire straights and needs it, the last thing you need is to have swap space consumed by a runaway process filling /tmp, consuming memory, causing pressure on the VM subsystem to swap to disk. Between swap activity, and the additional I/O streaming into the RAM disk (which in turn may cause additional page-ins to satisfy a seek() ) your system will quickly become I/O bound.

share|improve this answer
add comment

If you don't want it possibly eating RAM, I'd just run it as ext2. No reason to eat the small performance hit of journaling for a filesystem whose data you don't (shouldn't) care about across reboots.

Actually, scratch that, you should probably use ext4 and disable its journal, it should be faster than ext2. Format it ext4, and stick it in fstab with the mount option data=writeback.

share|improve this answer
add comment

Using ext4 with specific mount options should be fine. Use the following mount options:

barrier=0 : Significantly improves file write operations in some scenarios
noatime : Don't update file last access time, you don't need this on /tmp files and it should help with write operations performance.
share|improve this answer
    
add also nodiratime –  Weboide Aug 9 '10 at 1:40
    
noatime includes nodiratime –  zvolkov Nov 5 '11 at 13:59
add comment

I'm happy with ext4. You can play with some mount options if you like to tweak it or use tmpfs if you have a lot of ram.

share|improve this answer
add comment

In response to those asking about why you would want a separate /tmp partition, I'm sure there are many reasons, as some have already stated, but one that I find particularly relavant today is that if you are running / on an SSD, you want to minimize the writes to that drive, therefore moving /tmp is a good idea since it is an area of the filesystem that tends to change a lot.

share|improve this answer
add comment

I think tmpfs might be a bad option because usually /tmp is world writable so anyone can fill it up and if it fills up it will take all you memory and your server will slow to a crawl

share|improve this answer
    
I think setting a reasonable maximum size for tmpfs and having swap space will handle that. –  Olathe May 31 '13 at 16:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.