Optimal UNIX File System Partition + Setup Strategy

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.

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.

eg.

/ 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.

RAID
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.

LVM
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.