APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Partitioning for Linux

© February 2008 Robert Heller

Robert Heller
Deepwoods Software


This article discusses some of the things to consider when planning the partitioning of a Linux system. These considerations include thoughts on how different directories will be used and how the usage of different directories might suggest how to partition your disk space. Also my thoughts on the relationship between backup strategies and partitioning are covered.


1 The unified UNIX directory tree.

The overall file system structure on a UNIX system1 is always a single tree, no matter how many or how few physical or logical disks might be connected to it. This differs from MS-Windows, where each disk (physical or logical) gets its own drive letter and has its own independent directory tree root. Under UNIX (or Linux), having more than one physical or logical disk is generally invisible to the user, since each disk is seamlessly integrated into the directory tree. This means there is never an absolute need to have everything on one disk and means it is possible to have any number of physical or logical disks and that having more than one physical or logical disk has no effect on how the operating system is laid out and has no effect in terms of how programs are installed and installed programs can always find their data and configuration files in standard places without needing to know which logical or physical disk a given directory resides on.

2 One big partition vs. many smaller partitions.

Many people would like to install Linux (or other UNIX style operating systems) all on a single partition. Yes, one can do this and generally it will work fine. There are, however, various reasons to install Linux/UNIX on a number of different partitions. These reasons relate to efficient backup strategies, user and system protection issues (protecting users from system problems and protecting the system from user problems and protecting users from each other) and to help the system cope with unusual disk usage issues by certain daemon processes.

3 Common partitioning schemes.

The most common partitioning scheme separates the directory tree into 4 classes: core system, system volatile, user static, and user volatile file areas. Generally this scheme starts out with four partitions2: root (mounted under /), var (mounted under /var), usr (mounted under /usr) and home (mounted under /home). Generally the root and var file systems can be relatively small (about 1 gig for a typical modern Linux distribution) and the usr and home file system can be somewhat larger (about 4-6 gig for usr and arbitrary large for home).

The root file system contains the core system files. This includes the kernel itself (generally in /boot), the base set of user and system utilities (in /bin and /sbin), the system configuration (in /etc), the essential libraries and kernel modules (in /lib), and the device files (in /dev). These directories contain the minimal set of files and directories needed to boot up a Linux system, at least into single user mode. Most of the files on this file system do not change much. Mostly only a few of the files under /etc change at all (generally manually by the system administrator), once the system has been installed and configured.

The var partition contains the system volatile data files. This includes daemon3 pid and lock files as well as the spool and data directories used by various daemons. This file system (mounted under /var) is expected to be constantly changing over the course of normal system operations, mostly by daemon processes.

The usr partition contains the bulk of the programs, libraries, documentation, and constant data used by the normal user(s) of the computer system. Except when new system software is installed or existing software is upgraded, files on this file system change not at all.

Finally, the home file system contains the personal files of the end-user(s) of the computer. The files on this partition are regularly being created, deleted, and changed, generally at the whim of the end-user(s).

So, the first pass at creating partitions for a Linux installation would be something like this subset of the file systems on my home desktop machine (36gig SCSI disk):

Filesystem Size Used AvailUse%Mounted on
/dev/sda1 1011M151M809M 16%/
/dev/sda7 5.9G 2.7G 2.9G 47%/home
/dev/sda3 5.9G 3.5G 2.1G 63%/usr
/dev/sda5 1011M230M730M 24%/var

This uses roughly 14 gig worth of disk space. If you have additional disk space, you can make the /home file system larger4. I often limit the size of the /home partition, since that keeps my backups limited in size and use the “extra” space on the disk for a not backed up scratch file system. This scratch file system (which I usually mount under /scratch) contains random files I don’t need to back up, such as files I downloaded from the Internet (which I can always download again) or things like image files from a photo CD (which are implicitly backed up on the CD itself).

Here is another example, from my laptop, which has a 40 gig IDE disk:

Filesystem Size Used AvailUse%Mounted on
/dev/hda1 966M285M632M 32%/
/dev/hda5 3.8G255M 3.4G 7%/home
/dev/hda6 3.8G 1.8G 1.8G 51%/mp3s
/dev/hda7 24G 3.7G 20G 16%/scratch
/dev/hda3 3.8G 2.2G 1.5G 61%/usr

I’ve set aside a 4 gig partition to hold my MP3 files-I use my laptop as a sort of big bulky IPod. Virtually all of the MP3 files are ripped from CDs I own. Thus all of the files on the /mp3s file system are re-creatable, especially since I do have a backup of the scripts I used to extract and convert the audio files on the CDs on my desktop machine.

And yet another example from my model railroad control system:

Filesystem Size Used AvailUse%Mounted on
/dev/hda1 966M232M685M 26%/
/dev/hda6 7.6G139M 7.1G 2%/home
/dev/hda7 12G 3.1G 7.7G 29%/scratch
/dev/hda3 5.7G 2.2G 3.2G 42%/usr
/dev/hda5 1.9G198M 1.6G 11%/var
/dev/hda8 2.9G 1.8G931M 67%/WBL3

In addition to a (large) scratch file system, I also have a file system that contains ISO images of the operating system’s distribution CDs (/WBL3-White Box Linux 3.0).

4 Additional thoughts about special sorts of server classes.

On a server machine, it is often reasonable and very desirable to set aside one or more file systems (generally mounted somewhere under /var) for the volatile data used by the server’s daemons:

Daemon Typical mount pointDescription

Mail server (sendmail) /var/spool/mailMail spool and queue files

News server (inn) /var/spool/newsNews articles

Print server (lpd, cups) /var/spool/lpdSpooled print jobs

Web server (Apache) /var/wwwWeb pages

Database server (PostgreSQL) /var/lib/pgsqlDatabase files

5 Conclusions.

In conclusion, I’d like to say that there is no one “one size fits all” solution to how to partition your hard drive in preparation to the installation of Linux. There are many factors that need to be considered, including who will be using the system, how will they be using the system, how you plan on backing up files, how you (as system administrator) plan on resolving disk usage disputes amongst users, and considerations regarding server process disk needs. With a little careful thought and planning it is possible to come up with a well crafted partitioning scheme that will serve you for the life of the system (or at least the life of the hard drive(s)).

*Copyright (C) 2006 Robert heller.

1 Linux’s file system structure is a UNIX file system structure.

2 We will ignore the swap partition for the time being, since the swap partition is generally never part of the visible system directory tree.

3 A UNIX server process is known as a “daemon”.

4 But don’t forget about a swap partition!

Originally published March 17, 2006 at Partitioning for Linux. A PDF version is available at that link.

Robert Heller is a Linux and Unix consultant from Massachusetts. See his website at https://www.deepsoft.com/ for more information.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Partioning planning for Linux


Inexpensive and informative Apple related e-books:

El Capitan: A Take Control Crash Course

Take Control of Parallels Desktop 12

iOS 10: A Take Control Crash Course

Take Control of Numbers

Photos: A Take Control Crash Course

More Articles by © Robert Heller

Thu Feb 28 15:41:59 2008: 3723   TonyLawrence

The big objection to multiple filesystems used to be the difficulty of changing anything later, but nowadays many distros let you choose LVM at installation.

Another reason for splitting up filesystems is the ability to mount sections with different options - such as read-only for things that don't ever need to be written to.


Thu Feb 28 15:51:27 2008: 3724   TonyLawrence

One more thing: the original purpose for /dev/scratch was to use with fsck when there was too much disk and not enough ram for fsck to hold what it needs to hold. I haven't had to use a fsck scratch file for many years now..

Thu Feb 28 16:14:52 2008: 3726   jtimberman

Honestly this whole post is moot, and you said exactly why: LVM.

I haven't done individual disk partitions on a system since LVM became an option during installation. I've even gone back and encapsulated partition-based disk layouts with LVM (or EVMS). AIX and Solaris spoiled me.

Thu Feb 28 20:38:33 2008: 3729   TonyLawrence

Well, yes, LVM lets you adjust after the fact, but it's still good to have a decent starting point and not all systems offer LVM "out of the box".

Thu Feb 28 20:45:32 2008: 3731   jtimberman

Heh, well, I avoid that issue by not using any distributions that don't support LVM during installation anymore :-). At least, not for servers where disk sizing changes are more common.

Thu Feb 28 20:49:44 2008: 3732   TonyLawrence

I can't argue with that :-)

Fri Feb 29 16:40:43 2008: 3737   yungchin

This is a nice overview - it more compactly describes the general idea (splitting volatile/non-volatile and usr/system) than most other guides I've come across.

A few months ago, I tried to set up something similar (on top of LVM) for a laptop with Ubuntu but got it completely wrong...
I figured, going by the descriptions in the Filesystem Hierarchy Standard, that all I needed to do was to put /home, /var, and /tmp on their own partitions, and then I'd be able to mount / read-only. Well, add /etc to that - and it was more than just /etc/mtab that needed to be written to. What a mess...

I'd be interested in producing an updated guide that includes LVM and solves some other quirks, though. Any chance you'd want to work on that? (I'm hoping I'd inherit some linux skills and knowledge from you in the process :))

Fri Feb 29 17:06:04 2008: 3738   RobertHeller

Having separate file systems *partitularly* for /home, etc. has some other advantages -- for awhile my (old) laptop was dual boot: WBL 3.0 and CentOS 4.3 (both Linux). It has also 'saved my butt' when disks have started to die. And no, I was not bothering with LVM.

Mon Mar 3 09:49:37 2008: 3759   anonymous

One of the great things about maintaining a separate /home partition is that's it's easy to upgrade your distro or even change to a totally different distro but retain all of your settings. I have wiped my root directory (retaining /home on a separate partition) and installed a totally different distro over the top of it and, when I first log in, it looks and behaves much the same as it did before. I have the same wallpaper, all of my emails and bookmarks carry over etc etc.

Mon Mar 3 11:28:51 2008: 3761   JHoward

Still after reading this I see no reason for anything but one root partition and one home partition. /home preferably on it's own drive. I'm hoping someone will shine some light on this for me, but I just don't see it.

Mon Mar 3 12:19:19 2008: 3762   Rajagopal

I am not sure about this - can you boot from LVs created thru EVM or LVM? Perhaps a /boot on a local partiion is not a bad idea afterall.

Mon Mar 3 12:43:43 2008: 3763   RobertHeller

There are a number of reasons for haing separate partitions for root, /usr, and /var, as well as /home. Amongst them are:

Backup stratagies -- only (a small number) of files under / need regular backups (mostly under /etc), since everything under /usr is straight off the distribution.

Disk activity issues -- /var gets a lot of system traffic (/var/log, /var/spool, /var/lock, etc.), so this is a somewhat 'busy' read/write file system.

If you are using multiple kernels/distros, you might need a separate /boot file system. Depending on how 'close' the kernels/distros you may be able to share /usr, but not the root file system or /var.

If you are 'sharing' system file systems via NFS with diskless workstations (not totally 'thin' clients), the diskless boxes can chare /usr, but not the root file system.

For a web server, having /var/www separate makes sense and for a news server having /var/spool/news separate makes sense. Similar for mail, print, and/or database servers.

You don't need to have many separate file systems. This article just put forth some thoughts to consider.

Mon Mar 3 16:12:25 2008: 3769   anonymous

I never quite understood why web pages go into /var/www since they are largely static. As RobertHeller points out, read activity on html files more than makes up for the lack of write activity and therefore belong on a high activity partition...with the caveat that that partition is optimzed for that level of activity. At the very least, this would have to be a separate disk. Going a step further, I don't see the point of breaking out volatile and non-volatile tree if you are limited to one disk. The workload for that disk remains the same regardless of how you slice the pie. The only benefit then is to limit the damage a runaway process can cause if it's eating thru disk space.

Mon Mar 3 17:46:09 2008: 3772   RamboTribble

I'm a little surprised; no one seems to have mentioned the potential performance advantages of using different filesystems on different partitions. For example ext2 for /usr/bin and ext3 for /home. Why have the overhead of journaling if it offers little value?

Mon Mar 3 18:08:38 2008: 3774   anonymous

Except for the very weakest systems or the very highest loads, that overhead is probably virtually unnoticeable.

Tue Mar 4 03:49:02 2008: 3777   fukawi2

Someone forgot a swap partition :)

For desktops, I tend to just create / and /home for the reasons mentioned above (easy to upgrade without loosing things or having to restore backups)

For servers, I'll create up to 8 or 9 partitions:

/boot (read only)

/home (nosuid etc)

/var (prevents system dying if a daemon floods /var/log with errors and fills the partition)

/tmp (prevents users from filling the disk with a big file)

/usr (read-only; I remount it rw when I need to upgrade a file in there, otherwise should be no need to upgrade it)


/ (because you have to have one of these)

/srv (for file servers or similar, I'll dedicate a disk to the data storage and mount it under /srv then I can sym-link it from other places such as /var/www -&gt; /srv/www-root)

Tue Mar 4 18:18:50 2008: 3781   JHoward

Thank you everyone for their input - article and discussion; I feel enlightened :)

(this is a *good* thing)

Fri Mar 7 01:32:49 2008: 3793   anonymous

If you take the separate partitions route, you also need to factor in upfront an amount for growth (eg added apps in /usr, etc.)and headroom per partition. You should have about 25 % head room for each partition or disk performance will be degraded.

Fri Mar 7 15:17:02 2008: 3794   TonyLawrence

Well, again: if you use LVM, you can grow whenever you need to.

Fri Mar 7 16:56:45 2008: 3796   drag

For a low-end Linux server...

Dual core Cpu + 2GB RAM + AHCI-compliant SATA controller + 4xSATA drives + Software RAID 5 + LVM = very very very cool.

It's a winning combination and dirt cheap. So cheap you might as well buy 2 and mirror them and get the same level of fault tolerance that you used to have to spend tens/hundreds of thousands of dollars to get. Hell, might as well get a third and keep it off-site and rsync every evening and then your in data security heaven.

Raid 5 provides a decent level of performance/price/availability (but not data security! raid is not a backup) trade off for low end systems, software raid is cheap and fast, and LVM allows you to allocate disk resources on a as-need basis, on the fly.

As for the hardware, dual core because there is no reason not to and it's a good thing. Same thing with 2GB of RAM. RAM = file system cache as well as making software raid more effective. AHCI is a standard for storage controllers which Linux has good support for; supports NCQ, Full SATA support, hotplug, and power management features.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Java is C++ without the guns, knives, and clubs. (James Gosling)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode