Partitions are very important on Linux server because it give you a lot of flexibility, for example when upgrading to a bigger hard drive.

But, how many partitions should I create when building a Linux box ? Which size should I set for each partition ?

At last but not least, which partitions should I have on a separate disk (I'm thinking about /home, /var on perhaps a quicker drive, etc) and which partitions may I share on same drive ?

  • 1
    How many drives do you have? do you anticipate that number changing over time? Is this a single-purpose box or a general purpose one? Single user or multi? All these things matter. – pjz Apr 30 '09 at 16:05
  • The question is more on a general purpose but still for servers. – paulgreg May 5 '09 at 11:31
up vote 17 down vote accepted

Planning a good partitioning structure is heavily dependent on actually knowing how you are going to use the 'server'. Any random advice that doesn't take the actual services that will be provided isn't going to be particularly useful.

For example if it is a debian-based box that will be used for mysql you might want a seperate partitions for /,/var, and /var/lib/mysql.

Is it going to be a file server with lots of shared storage? You might want a /, /home, and /srv partitions.

For a box running only squid, you might want on partition for /, and one partition on a fast disk for the squid spool.

As you are planning your partitions it is very helpful to have a good understanding of the Filesystem Hierarchy Standard and if/how your chose distro deviates from the standard.

Using LVM can make it much easier to change your mind in the future and adjust your partitions without having to reboot., and its ability to create snapshots can be very easy to create good backups.

I always create these partitions, and as of the last year, always on LVM:

/       - a few Gig
/usr    - 24 Gig and mostly empty
/var    - 4 Gig works for me, YMMV
/home   - depends on how many users you will have

One of the most important is /var -- if this is a separate partition, then when it fills up, you will not crash your root partition. Although I have never done this, some make a separate /usr so that they can mount it read-only.

and I sometimes create these partitions:

/boot   - even 1 Gig is way more than enough

The reasoning is that it's not always possible to boot from a RAID or LVM partition. Thus, /boot can be a simple ext3 partition, allowing / to be more advanced.

If I will have a large number of large files, I will sometimes create a specific partition for these large files so the filesystem can be tweaked to be efficient at storing large files. Some people, if they will be serving NFS from a server, will create a separate partition for their NFS shares or even a separate partition for each NFS share. This depends on your needs.

Why LVM? As I've mentioned in answers elsewhere but forgot to mention here, it makes it a LOT easier to change your mind later and expand a partition. This has saved my butt already.

These are general guidelines. Of course, I expect that if your server has special needs, you'll take that into account and make partition reflecting these needs.

Assuming that you're building a machine that's going to last a while, would be inconvenient to rebuild, and needs to be pretty flexible, you might like a scheme similar to the following:

  1. Install a minimum of two physical drives, the same size; for the purposes of this example, I'm going to assume 500GB SATA drives, but the principles work just fine with other sizes of drive.

  2. Partition each drive as follows:

    /dev/sda1   500MB
    /dev/sda2   100GB
    /dev/sda3   the rest

    The goal is to have a dinky 500MB partition up front, a sizeable partition in the middle for the OS and applications, and the bulk of the drive at the back for additional data.

  3. Build a SW RAID 1 set, /dev/md0, from /dev/sda1 and /dev/sdb1; build additional SW RAID 1 sets /dev/md1 and /dev/md2 from the corresponding paritions.

  4. Format /dev/md0 as ext3; this will be /boot.

  5. Format /dev/md1 and /dev/md2 as LVM physical volumes.

  6. Create a LVM volume group, vg_system, which contains /dev/md1.

  7. Create appropriate LVM volumes inside vg_system for your various OS partitions; at the very least, you'll want swap, /var of a couple GB, and / of 10GB or so. NOTE: do not allocate all of vg_system! When you later decide that you want to increase the size of \var, or you want to add an /opt or whatnot, then you'll want that additional space.

  8. Create a LVM volume group, vg_data, which contains /dev/md2.

  9. Create LVM volumes inside vg_data as desired; at the very least you'll want a sizeable /home, and you may want additional volumes for, say, mail spools, or databases, or web roots, or any other data that isn't part of the OS. Again, don't allocate all of vg_data, for reasons similar to the ones listed above.

The advantages of this strategy include the following:

  • It's tolerant of hardware failures; either drive can fail without causing a system failure, and if you invest in a hot-swap controller, you can recover without downtime.

  • It's future-proof and expandable; when you buy 2TB drives a few years down the road, you can slap them into the machine, make them into another SW RAID set, format it as an LVM physical volume, add it to whichever volume group needs more space (probably lv_data), then use pvmove to migrate your data off the old drives and onto the new. In addition, major OS updates can be rendered significantly less painful; if you need to reinstall the OS for a major upgrade (ahem Red Hat :( ), you can do so while preserving home directories (and mail spools and whatever all else you put in vg_data).

The disadvantages of this strategy are few; I suppose it's a bit complex, and you do take a performance hit on writes because of the RAID 1. However, I've been building workstations and standalone servers according to these principles for some years now, and in my experience every time I don't build a machine along these lines, before long I wish I had.


P.S. I should add that if you have the infrastructure in place to quickly and painlessly provision a new machine, then a system like this is overkill; rather than tinkering with RAID sets and LVM, just rebuild the machine if you need something changed.

For years every computer I've used has been a dual boot system, and on the Linux side I pretty much stuck with this schema (I'm talking personal workstations here, no server stuff, so your mileage might vary)

/     - main thing
/boot - not that relevant, since cylinder being < 1024 and 
        exotic filesystems are no longer an issue
/home - handy if you upgrade your laptop with each new distro :-)

For my last upgrade I did an install from scratch, wiping out my / partition. That made me think a separate /opt or /usr/local partition would have been nice, sparing me the hassle of reinstalling all the stuff I put in there (java, eclipse... I usually don't care for the distro packaged ones).

In addition to the partitions mentioned by Eddie, I typically create two more separate partitions

/tmp - for the same reasons you created a separate /var partition (I've had the temp space all fill up before). I typically go with 1-2 GB

/usr/local - This allows you to upgrade and clean /usr as needed without blowing away all your separately installed software. The size here depends on how much external software you install. I typically go with about 10 GB but am finding that to be a bit small these days.

I always make /home last and fill up the rest of the disk with it.

On the /boot partition, I've never made it bigger than 100 Mb and never run into space problems (I clean out old kernels eventually). It really can be very small.

Also don't forget a swap partition as well.

For most machines, I do

100MB /boot
10GB /var/log
10GB /var

In some cases, this will need to be switched, but I'm pretty adamant about users not getting more than 1GB of space on a server. If they need more, they can use /tmp, with the understanding that it will be deleted via cron nightly.

Assuming that you don't use a hardware RAID there - under Linux I would always use LVM on top of RAID. Even for a single disk configuration. Reason being that you have the option to add more storage space (by extending the LVM group) or change the redundancy options (say turning a "weird" single disk raid1 config into a mirrored one or even RAID10 with some heavy lifting).

To answer your question I usually have something similar to this for a generic server. Starting with 2 disks (say a 1RU Dell), both partitioned as:

  • ~100MB RAID1 for /boot
  • LVM on top of RAID1 for the rest of the disk

Then we create all the volume as LVM volumes: * / * /var * /tmp * /home * /opt

I would avoid creating too much filesystems as it's a pain to manage. If you are running low on disk you will end up having free space across many filesystem but not enough to do work on.

/home and /tmp on a separate filesystem is always a good idea; generally I don't separate /opt unless I'm planning to put a lot of stuff in it. (NFS might be a better option for /opt if you have lots of servers that requires the same software stack)

In short, use LVM for everything unless you have a reason not to - that way you have the option to change.

Also, use a log server so logs won't fill up your /var!

  • /boot - 128MB

Volume Group - rootvg

  • /var - 5GB (depends if it's used as a mail server. You can also resize to catch core files)
  • /tmp - 2GB
  • /opt - 10GB (used for software that doesn't come with the distro)
  • / - 6GB - minumum

Volume Group - datavg

  • /home - the rest

You can make a separate /usr for your software but in my case the box gets reinstalled, so no need to get its own partition.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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