So recently a Debian 5.0.5 installer offered me to have separate /usr, /home, /var and /tmp partitions (on one physical disk).

What is the practical reason for this? I understand that /home can be advantageous to put on a separate partition, because user files can be encrypted separately, but why for anything else?

  • 15
    Another good reason for keeping /home separate is that it lets you reinstall your system and/or switch distros freely without losing your personal files.
    – David Z
    Commented Aug 19, 2010 at 1:06
  • 4
    @David Zaslavsky: I wouldn't recommend it for switching distros. as more often than not the hidden configuration files in your home directory will conflict.
    – Troubadour
    Commented Aug 20, 2010 at 13:16
  • 10
    @Troubadour: Actually I don't think so. Those configuration files are placed there by specific applications and generally don't have anything to do with which distribution you're on. So for example, the content of ~/.mozilla/firefox can be used equally well by Firefox on Ubuntu or Fedora or Gentoo. ~/.bashrc will always have the same effect on Bash, no matter which underlying system you run. I've done a fair amount of switching distros and never really had a problem with those configuration files.
    – David Z
    Commented Aug 20, 2010 at 17:32
  • 5
    @David Zaslavsky: I could see problems arising if the new distro used earlier versions of applications than the previous, since they might not know how to read those config files. That being said, I've not tried to do anything of the sort myself.
    – intuited
    Commented Jan 19, 2011 at 3:44
  • 1
    As another reason, if you're using both a hdd and a ssd, you may want to have the bulk of the installation on the ssd, but want to put, say, /home and /var on the hdd to avoid a large number of writes to the ssd.
    – Kevin
    Commented Sep 5, 2015 at 18:54

10 Answers 10

  1. Minimizing loss: If /usr is on a separate partition, a damaged /usr does not mean that you cannot recover /etc.
  2. Security: / cannot be always ro (/root may need to be rw etc.) but /usr can. It can be used to make ro as much as possible.
  3. Using different FS: I may want to use a different system for /tmp (not reliable but fast for many files) and /home (has to be reliable). Similary /var contains data while /usr does not so /usr stability can be sacrifice but not so much as /tmp.
  4. Duration of fsck: Smaller partitions mean that checking one is faster.
  5. Mentioned filling up of partions, although other method is quotas.

A separate /usr can be useful if you have several machines sharing the same OS. They can share a single central /usr instead of duplicating it on every system. /usr can be mounted read-only.

/var and /tmp can be filled up by user programs or daemons. Therefore it can be safe to have these in separate partitions that would prevent /, the root partition, to be 100% full, and would hit your system badly. To avoid having two distinct partitions for these, it is not uncommon to see /tmp being a symlink to /var/tmp.

  • I guess I can understand /var and /tmp, but since the installer offered to partition a single disk, the utility of a separate /usr is quite limited then?
    – Alex B
    Commented Aug 18, 2010 at 12:56
  • 1
    It allows you to share /usr through NFS to other systems. But you could share it even if it is not a separate partition, that's true ... thinking aloud ... Is read-only mount a good enough reason? Commented Aug 18, 2010 at 13:14
  • How do you do updates with this sort of setup? Often (at least under Linux) packages will make changes to files in system-local directories, for example in /etc.
    – intuited
    Commented Feb 16, 2011 at 15:44
  • 1
    +1 for /usr read-only mount. Remount it rw before doing updates.
    – LawrenceC
    Commented Apr 5, 2011 at 14:39

Because ordinary users can cause things to be written to /var and /tmp, and thus potentially cause problems for the whole system. This way user processes can fill up /var and /tmp, but not the root fs. A separate /usr is useful for /usr over NFS, or other remote fs.

(I hope this is clear, I haven't had any coffee yet)

  • 1
    The first sentence is the best explanation, thank you. Commented Apr 6, 2011 at 6:54

The issue is that a full root fs makes the Linux system unoperable to an extent where even a sysadmin won’t be able to fix it without using a live CD. When /tmp, /var and in specifically /home are on a separate partition, the root fs cannot fill them up without root access. Add the /usr directory to the mix in where all the usual installs will be placed, and even installing new software cannot cause this problem.

  • 2
    Unless it installs into /opt :)
    – Troubadour
    Commented Aug 20, 2010 at 13:23
  • 1
    Well. you can make a different partition for this as well, or create a link such that /opt is actually located in the /usr partition. The principle is still the same.
    – txwikinger
    Commented Aug 20, 2010 at 14:30

In general, the arguments for having separate partitions are:

  1. Security: you can, for example, mount a partition read-only to keep malicious users (or processes) from overwriting or replacing binaries there with trojans. So if your ssh binary lives in /usr/local/bin and /usr/local is mounted read-only, it's going to be tough for anyone to replace that binary.

  2. Flexibility/Convenience: for example, if you set up /var on its own partition and it gets to 80% full, you can resize it, or even move it to another disk if need be. I'd rather have to do that than deal with a system whose '/' is 100% full because logs under /var have gone haywire in some way. Different partitions can also have different filesystems entirely, allowing your OS to use ext3 (for example) and your database to use ext4, or your object repository to use XFS, or your custom app to use... raw devices!

  • What's the usual way of handling system updates in the first case?
    – intuited
    Commented Feb 16, 2011 at 15:48

Traditionally, it was done this way because of peculiarities of the DEC hardware that it was developed on. It was more economical to buy a small, fast disk for root and swap and a larger, slower disk for user data (/usr). In some ways the convention just stuck.

However, there are still some reasons for doing this. A few common ones are:

  • Putting /boot onto a separate, small partition close to the beginning of the disk. Older PC BIOS firmware would only boot from the first 1024 tracks of the disk. This is less likely to be a problem with modern hardware.

  • Putting busy partitions such as /var or /tmp onto separate disks to remove bottlenecks on access to user data.

  • Different file systems on different partitions. For example, you may wish to use a journalling file system for /usr but not for partitions that host files for a DBMS such as Oracle - the DBMS does its own journalling and the journalling file system may impose significant overhead.

  • Having user data on a separate disk or partition makes it easy to migrate it onto a larger disk without major surgery on the machine.

  • You may wish to mount shared data such as home directories or application binaries over NFS.

  • fsck takes a long time on large volumes for certain types of file system. You may wish to have different file system maintenance schedules for system areas (frequent) and user areas (less frequent).

  • Using separate partition on the same hard disk is slower than having 1 whole partition. I remembered reading lots article from Microsoft where they ever told people not to separate partition too much because it can make your computer slow. Point number 2 I don't agree.
    – MaXi32
    Commented Dec 13, 2020 at 18:11
  • It would be unusual to bother doing it in this day and age, but there were applications such as usenet news that would give /var a pretty good workout on the hardware of the day. In some cases it made sense to put this on its own disk so that the heavy I/O on /var didn't interfere with other functions of the machine. Commented Dec 14, 2020 at 10:13

Formatting a filesystem can also be faster than rm -rf'ing it. Especially if you have thousands of small files to erase. Squid cache you want to fully re-create... tons of image files that your need for processing but can be thrown away after the end result is created. .obj files from huge compiles... etc.


A folder I sometimes put on a separate partition is /usr/local/ so that any software I've built and installed separately from my distro's package manager could possibly be re-used if I change/upgrade my distro or by another distro installed along side it. It's obviously not guaranteed to work across all possible combinations but it does no harm.


I put /tmp on a tmpfs, so the contents are stored in RAM instead of on disk. That wouldn't be useful for /etc or /usr however.

But being able to put different directories on different filesystems could be beneficial; i.e. /home on a fast/experimental filesystem like ext4 vs a stable/reliable filesystem like ext2 for /etc.


Several of the answers talk about having /tmp and /var on separate partitions to not get / full which might break the system.

But if you do get problem with a full / it's usually because the system cannot create or write to either /tmp or /var so having these on separate partitions will not help.

That is if /var or /tmp gets full its quite likely that your system will missbehave.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .