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):

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