A Good SSD/HDD Partitioning Scheme

An SSD is a great investment. Data loads super fast and there are no moving parts to fail. But SSD storage space is expensive, and most users have a lot to store. A common solution is to install the OS to the SSD, and move personal data (the `/home` directory) to a secondary HDD. While this is the easiest way to take advantage of SSD speed, the results are less than ideal. SSDs have a limit on write cycles so it is wise to minimize disk write operations. My preferred solution offloads some of the more volatile areas of the Linux filesystem to the HDD as well.

The table below shows how I partitioned my 32GB SSD (`/dev/sda`) and my 320GB HDD (`/dev/sdb`):

Partition Size Type Mount Point
/dev/sda1 512M ext4 /boot
/dev/sda3 23.5G ext4 /
/dev/sda5 8G ext4 /usr

/dev/sdb1 4G ext4 /var
/dev/sdb2 4G swap
/dev/sdb5 192G ext4 /home
(120GB Unpartitioned space on /dev/sdb)

This scheme takes advantage of the SSD’s speed in areas that matter, while making sure to maximize its lifespan by minimizing write cycles. Below we’ll take a look at each partition in more detail.

### The `/boot` Directory ###

A long-standing convention states that `/boot` should be its own small partition at the front of the disk. This goes back to old BIOS limitations which no longer apply. Nevertheless, I prefer to maintain this convention because it’s familiar and logical. Some Linux admins keep `/boot` on its own partition so that it can remain unmounted by the running system for security reasons. This is possible because the files in `/boot`, while accessed by the bootloader, are generally ignored by the kernel and other processes. If you do this, it is good to leave a `/boot` entry in `/etc/fstab` so that the partition can be easily mounted for such tasks as bootloader configuration and kernel image updates, but append the `noauto` option to prevent the kernel from automounting the partition on boot.

**Note:** Before you decide to leave your `/boot` directory unmounted, consider the following. Many package managers include kernel updates as part of their normal update process. If your package manager does this, it will likely write the updated kernel image to the empty placeholder `/boot` directory on the root partition, but GRUB will still try to read the kernel image from the `/boot` partition (remember that GRUB uses its own syntax to refer to filesystems), and thus will fail to find the appropriate kernel image. Don’t do this unless you know what you are getting into, or if your distribution is such that you build and install your own kernel images rather than relying on a package manager to do it.

It is worth pointing out that only very recent versions of GRUB support the ext4 filesystem, so you may want to use ext2/3 here instead.

### The `/` (Root) Directory ###

It seems obvious that the root directory should be on the SSD–it is the operating system. If this directory were moved off the SSD, the upgrade would be rather pointless. Locating the root partition on the SSD will result in fast booting and loading of programs. Moving on…

### The `/usr` Directory ###

The `/usr` directory stores most of the binaries and global program files on a Linux system. I prefer to mount `/usr` as its own partition. Other than `/home` and `/var` (as well as `/srv` on some machines), it is the only directory of substantial size in the Linux filesystem. Partitioning it off can help make the process of imaging disks for backup more efficient (i.e. an admin may not want to back up `/usr` as often as the rest of the filesystem–it only changes when packages are upgraded).

### The `/var` Directory ###

The `/var` directory is probably the most volatile directory on any given Linux machine. That’s because it’s where log files are stored. Moving this directory to a standard disk drive can save a significant number of writes to the SSD. While it is true that the writing of log data will take longer this way, the Linux kernel uses advanced I/O caching (writing files to RAM until the CPU has free time to write them to disk), so there is no noticeable decrease in performance.

### Swap Space ###

It may be tempting to move swap space to the SSD, since it would make swap operations much faster. But SSDs are about gaining high performance, not making up for bad performance. If a machine has so little memory that the OS is forced to use swap space frequently, the admin is better served to spend his upgrade dollars on more RAM before springing for an SSD. For this reason, and because those 4GB of SSD space are precious, it is wise to put swap space on the HDD.

### The `/home` Directory ###

The `/home` directory is the conventional location for the storage of documents, photos, music, videos, and other personal files. It is also the location of user-based configuration settings. When a user launches an application, that user’s personal settings are loaded from the `/home` directory. This leads some to suggest that putting `/home` on the SSD will speed up load times. Whereas this may be the case, most of the settings are stored in simple, tiny, text-based config files, and any difference in program load times would be completely indistinguishable by the user. Rather than complicate matters by partitioning subdirectories of `/home`, it is more sensible to create a separate `/home` partition on the HDD and be done with it.

### Other Considerations ###

The scheme described above is limited in scope. Below are some other things to consider when designing a partitioning scheme.

#### `/srv` ####

Servers often store content in the `/srv` directory instead of `/var`. While `/srv` is a rather new convention to the Linux FS hierarchy, it is becoming quite popular. If your distribution uses `/srv`, it is probably a good candidate for partitioning off to the HDD.

#### `/lib` ####

Shared libraries, stored in `/lib`, are often accessed by programs on load, and thus should remain on the SSD. But because the `/lib` directory can become modestly large (although usually much smaller than `/usr` or `/var`), some admins prefer to create a separate `/lib` partition on the SSD for much the same reason as `/usr`–that is, to make backups more efficient. There is nothing wrong with this decision. It is simply a matter of preference.

#### Unpartitioned Space ####
Many admins prefer to reserve unpartitioned space on a disk in order to accommodate unforeseen circumstances. As long as the existing partitions have plenty of room for growth, this can be a wise decision. A good rule of thumb is to make each partition twice as big as you think you need, and to leave the remaining space unpartitioned.

### Conclusion ###

While no single partitioning scheme will suit every machine, the scheme described above is a good starting point. What would you do differently? Let me know in the comments.

12 replies on “A Good SSD/HDD Partitioning Scheme”

RAM disks are designed to improve performance for filesystems prone to bottlenecks due to high-volume I/O operations (such as busy database files). Many multimedia apps make working copies of files in /tmp, which could take up a lot of space. Using a RAM disk in those cases could slow your computer down significantly. If you choose to do this, use tmpfs and set a reasonable size limit for the filesystem. But in most cases it’s probably fine to leave /tmp on the SSD, or create a hard disk partition for it if storage space is a concern.

can i move any of the above directoies post install. if so which ones? or visa versa.
if required: ubuntu 12.04×64 (dual boot windows7HPx64), SSD(esf4) and HDD(efs4).
thanks in advance

have a 120gb ssd and plan to use in LMDE as JFS. What partitions should I use to maximize speed, minimize writes? Feel free to offer any suggestions!
Suggested chart below:
/boot 250mb primary
/root 20gb logical
/home 50gb logical
/usr 8gb logical
/lib 1gb logical
/var 4gb logical
/opt 2gb logical
/srv 1gb logical
/tmp 1gb logical
33.75 unparted

I sure appreciate the help as I have not been able to find anything any more concise as you have here.

Not sure which distribution you’re using but take a look at the Arch Linux Wiki page on SSDs. There is a lot of good information here that you may need to know to make sure you’re truly taking advantage of your SSD’s speed. It’s not necessarily concise, but as is usually the case with the Arch Wiki, you will walk away with a much deeper understanding of your own system and Linux in general.

I will be getting a similar setup with 32gb SSD and 500gb HDD. Should I leave unallocated space in the SSD? I read that doing so would improve longevity of SSD, but I don’t know…

There’s no benefit to leaving unpartitioned space on an SSD. Modern SSDs are designed to maximize drive life by “staggering” writes, so they properly manage unused space automatically, out of the box.

Thank you for this information! I spent hours sifting though quickly drawn-up solutions for SSR/HDD setup until I found this well-written article. Much appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *