I'm about to reformat and reinstall CentOS onto an old server. The server runs on a modest 30 node small business network and has a variety of responsibilities including MySQL, a Samba share, DHCPd & SVN/Trac.

The old sysadmin had this server setup with almost a dozen different partitions for various things. I'm trying to understand what the advantages of multiple partitions are as opposed to a just one filesystem at /. Speed? Flexibility? Security?

It seems like if you misjudge the necessary size for any given partition and it ends up filling up too fast, it requires a sysadmin to go in and expand the partition, etc... Seems like it would be easier if everything was just one flat / filesystem. But I'm sure there are some advantages I'm not aware of.

The server is currently running a handful of HDDs raided to ~2TB (raid 0).

  • Wait...when you say "raided to" what kind of RAID are you talking? – Bart Silverstrim Feb 4 '11 at 17:29
  • 1
  • If you are going to use lots of partition these days, you should almost certainly be using them with something like LVM which allows you to dynamically resize partitions. – Zoredache Feb 4 '11 at 17:35
  • @Zoredache: I can't believe I'd never upvoted you on question 61284. Fixed now. – Evan Anderson Feb 4 '11 at 17:42
  • 2
    Are you sure that it's running RAID 0? If so, that's the first thing that you need to correct. – MDMarra Feb 5 '11 at 5:41


  • different mount option(noatime to squid cache)
  • overfill protection(overfill /var/log)
  • no need to mount all the partitions(such /boot)
  • different file system


  • fast move between partitions
  • common space

The main reason is isolate the partitions from one another. There can be many reasons why you would wish to do that.

/var is usually a separate partition to prevent runaway logging from not allowing you to create files outside of /var.

/tmp is another partition that may get full and additionally you may want /tmp to be a ram-based file system.

Users tend to fill /home and additionally you may wish to preserve it when re-installing the OS.

Quotas apply on a per-partition basis.

Some backup software works on a per-partition basis. You may wish to backup /srv but not the OS because you have an automated provisioning system.

You may need different performance characteristics of different partitions.

Some of these may not apply to you. I would probably at least have a separate /var, /tmp, and /srv (or wherever you put your MySQL, Samba, and SVN data).


There's really no need for multiple partitions. Traditionally you had a partition set up by the system and another for data in case there was overfilling...fill the partition and you risk the server being unusable.

Advice I've heard is usually a partition for swap, one for system, one for your data...and if you want, another one for home directories. Just to make a physical stop to large amounts of data filling things up (like logfiles...they can get out of hand easily). And one for logfiles. :-)

Nowadays I normally follow the installer's advice on what to create unless I have a particular scheme in mind. Depends on usage patterns and purpose of the server. With that much space you shouldn't have too much worry about logfiles eating up space, especially if you monitor the system with an application that will warn you of disk space usage.

Although you should keep the system files in their own space...just for recovery purposes.


I setup all of my boxes with exactly 2 partitions. One for boot, and one for everything else. But the "everything else" is an lvm with a bunch of logical volumes (/tmp /var /usr /home /opt /root). I don't use all the space in the LVM, and then can independently grow any volume that needs more space.

At the minimum, I would separate out things that can grown with a mind of their own like /home and /var, so that you don't have things hanging when the filesystem fills.

Basically this sort of setup gets you flexibility in sizing, and protection from one user filling up an entire drive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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