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.
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
There are several good choices here:
none /tmp tmpfs size=64M,mode=1777 0 0to your
/etc/fstab. You can change the
sizeto a value you like. If you think at some point that it is too little, you can use
mountto 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.
/tmp, checking it will take some time. ext3 boots faster in many cases. Therefore I would suggest the use of journalling.
/tmpfor 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
If your computer runs for a long time, it is a good idea to delete unused files in
tmpreaper is one solution which does that for you.
However my first choice would be using
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
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):
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.
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.