When partitioning a new system disk(s) for UNIX, what is your prefered strategy for both desktop and/or servers?

Please include disk partition layout, file system format(s) and options, mount points, RAID level(s), LVM groups and volumes, encryption, and any other relevant settings.


I'm a fan of LVM for this kind of problems. You just need some space for /boot (i use about 100MB). Combined with filesystems which can dynamically grow and shrink (or at least grow) you never have to think about to small partitions again.

On my desktop I use an LVM with XFS as filesystem for all partitions. I create as small as possible and let them grow as I need more space.


If it is Linux, have a separate /boot.

For other Unix variants, typically, I have recommended partitions for / and /var, data is usually mounted at /u001, /u002 etc.

Previously, there was a need to heavily partition as disk space was limited and you did not want a single filled partition to bring down the entire system. With the greatly increased storage available today as well as the plentiful resizing and virtualization options available, the need for many partitions IMO has gone down. That coupled with the fact that it's a hassle to move things around when you have many partitions means that if you can get away with less, do it.

Having swap as 2xRAM does not make sense when you have say 32GB of memory. So remember, the "rules" are really guidelines and some simply do not make sense in light of the newer hardware available now.

  • 2
    +1 on mentioning the need of partitioning going down lately, besides if you need more space in /home you could always mount a new harddrive.
    – Spoike
    May 1 '09 at 6:28
  • 1
    +1 - I agree w/ downplaying the need for crazy partitioning games on most systems. If you know that you need /var to be on a fast disk because of some application, so be it. More often than not, when I've run into crazy partitioning games in production systems it's been a single hardware RAID-1 volume carved up into a bunch of little partitions, all waiting to fill up and need to be resized (to make work for the admin, apparently). If you know you have an application for some kind of complex partition scheme, go for it. If you don't, you don't. Jun 6 '09 at 3:14

Planning a good partitioning structure is heavily dependent on actually knowing how you are going to use the system. Any random advice that doesn't take into account what the system is doing isn't going to be particularly useful.

All the fancy filesystems may be useful on occasion, but if you want a stable system it may be a better idea to just stick with the 'standard' filesystem (i.e. ext3) unless you have a very good reason to use something else.

RAID is good, I always run RAID1 on all my personal computers because I have had too many hard drives fail.

Encryption with something like dm-crypt is good if your system is a portable device, has high-value data, or your just paranoid.

As you are planning your partitions it is very helpful to have a good understanding of things like the Filesystem Hierarchy Standard and if/how your chosen unix 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. Use LVM, and don't immediately allocate all of your space.


There are two very good reasons to partition besides FS type:

  1. Prevent overspill from an application affecting the functionality of the system. If your app fills /usr, then it's useful to have some space left on /var to allow the system to continue and logs to be recorded.

    Jauder said above that this is negated by the size of hard disks today - I don't think this is strictly true. Our drives might be bigger but the data we're turning over is ever increasing. There's no need to get complacent.

  2. Mount options. You can define more carefully what permissions each partition should adopt. For instance it's good practice not to allow files to be executed, especially suid's, from /tmp as it's a common attack vector for machines serving web applications. Unless you are running jails you shouldn't expect to see device nodes anywhere but /dev. And so on.


/ noatime  
/tmp noatime,nodev,nosuid,noexec  
/var noatime,nodev,nosuid  
/usr noatime,nodev  
/home noatime,nodev,nosuid  

Physical Disks Partitioning
Start with 2 disks minimum:

#1 100MB,     ID=83 (Linux), Boot Flag ON
#2 Remaining, ID=FD (Linux Raid Auto)

The 100MB partition is for the /boot volume. I leave this on all my drives (even non-boot) to allow for flexibility so any drive can be later enabled to boot. IF the disks are not matched in size, or you have an odd number (500GB, 250GBx2), then divide the partitions of the 500GB drive to match the smaller disks.

Using the 100MB partitions on sda and sdb create a RAID1 (mirror) volume for /boot. This becomes md0.

md0        /boot          100MB          Ext2

Don't bother using an exotic FS on /boot, it's not worth it.

The remaining space can be set up in different methods. I opt for a RAID10 (mirror/stripe) using 64K chunks and "2 far-copies" for speed. This gives you a lot of flexibility to incrementally upgrade drives down the line. The other options is to do a RAID5/6. However the usable space will be limited to the smallest partition, and DO NOT use partitions from the same devices. Name the new RAID arrays md1, md2, and so on.

Take all of the RAID arrays except md0, and put them into a single LVM volume group named lvm_vg0. If you have RAID5 and RAID10 volumes, it's probably best not to combine them, but I guess it wouldn't hurt.

Partition out VG0 for the remaining system mounts. Remember it's relatively easy to add more space if needed, so these numbers can be somewhat conservative.

lvm_vg0-root   /      8GB     Ext3/ReiserFS  (core distro files)
lvm_vg0-home   /home  20+GB   Ext3/ReiserFS  (user data, documents)
lvm_vg0-data   /data  60+GB   XFS            (media, large files, vm's)

XFS file systems cannot be shrunk, so keep that in mind. Also, shrinking an online root volume is probably not supported.

Upgrading If you ever want to swap disks for larger sizes you have a few options. The easiest is adding drives in pairs or more, and add the new RAID arrays to the current LVM VG.

Another option is adding a single drive that is >= to the sum of the current space. For example, if you have two 100GB device in RAID10, you can add a new 200GB device and mirror it using the two old devices. This is more error prone, but will work.

If needed, md# devices can be removed from the LVM VG without losing data. This can be done if there is enough free LVM space to shift all used LVM blocks from the md# device to others. LVM can only use space that has not been assigned to a LV, so an empty file system does not count as "free" space.

  • 1
    I'm not convinced by the fear of exotic file-systems on /boot. ext3 and XFS are no longer exotic in 2009. It used to be a concern when liveCDs weren't packaged with drivers for them, but nearly all are these days.
    – Dan Carley
    Jun 17 '09 at 8:30
  • @Casey, you can shrink an Ext3 volume "live", provided you have enough free space for stuff to move into. Yes, this is a nail-biting experience, but I've done it, and it does work as advertised. Just be VERY careful with the parameters. Sep 8 '09 at 21:37

I just run Linux Workstations. I use the ext3 file system and the sizes somewhat depend on the size of the disks, being more generous with the partitions on the larger disks. These are roughly in the order they appear in the partition table:

  • /boot - 100 MB
  • swap space - 2xRAM
  • /usr - 10-20 GB
  • / - 5-10 GB
  • /var - 1-2 GB
  • /tmp - 1-2 GB
  • /usr/local - 10-20 GB
  • /home - everything else.

On my wife's workstations at the university, which have two 750 GB drives, we created, in addition to the above, a dozen ~100 GB partitions across the various drives all mounted in /data/N where N was a number from 1 to 12. She uses these to hold the data for her different research projects.

  • I personally don't see the advantage of having /var, /usr seperated off to a different partition. While /usr/local may be a good idea if you have custom installed software (=not installed via packet managment), the two mentioned are imho pretty useless. Also 2xRAM as swap is imho unneeded. If your system begins to swap everything gets dead slow, so you want to avoid this in the beginning. I personly only hav a swap partition with Ramsize+X because I use suspend-to-disk sometimes.
    – Martin
    May 1 '09 at 4:15
  • 2
    @Martin, On linux box acting as a squid cache you want your spool dir, and log dir to be on a fast disk, and you usually don't need that disk to be reliable. One might put (/var) your spool on a RAID0(stripe), and leave everything else in slower drive.
    – Zoredache
    May 1 '09 at 8:07
  • @Martin - You're right, splitting /usr off is probably unnecessary and I don't always do it anymore either. The swap = 2xRAM is an old habit left over from the days when I've was configuring systems with only 256 MB RAM or less.
    – dagorym
    May 1 '09 at 14:38
  • 1
    actually, splitting /usr and /var allows you to enable journaling on one and not the other.
    – Scott
    May 6 '09 at 17:24
  • 1
    And putting /var on a separate partition makes sure only /var can fill up with log files, which could otherwise have brought your system to it's knees.
    – wzzrd
    Jun 17 '09 at 8:29

use noatime on all disks (unless you have a reason not to) I mount /tmp in tmpfs although this may not be so good on a server, I'd make sure it's a separate partition and mount it nodev,nosuid,noexec,noatime. I always use ext2 for /boot so I don't have to worry about changing fs stuff screwing my ability to boot w/ grub. ext4 on everything else, I use journal=data on /home which probably slows things down a bit (as it doesn't have dealloc) but I've never lost data with journal=data either, and being a bit of latest/greatest whore, sometimes my system locks up and I have to hard reset it (because I tried something like kms and found a bug).

  • 1
    Don't forget to use 'nodiratime' as well, otherwise you'll pushing on your vfs_cache_pressure with tons of inodes (plus the actual writes to disk!).
    – Gazzonyx
    Jun 30 '09 at 12:35

Wow, nice question. Been surfing for the perfect answer for this for yonks.

I personally have 50Mb /boot ~8GB / and the rest goes towards /home Thats far from the perfect though. I need to investigate alternative filesystems, currently I use ext3 but I've heard great things of other filesystems for example XFS.

I usually also create a file container for /tmp purely so I can be more flexible with it in future.

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