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?
/usr is on a separate partition, a damaged /usr does not mean that you cannot recover /etc./ 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./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.
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.
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)
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.
In general, the arguments for having separate partitions are:
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.
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!
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).
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.
