Improving SSD Lifespan on Linux: What I Learned Not to Do

While Solid State Drives (SSDs) can provide a significant performance boost over traditional Hard Disk Drives (HDDs), there is one downside which often concerns users: longevity. Although, with general day-to-day usage, the average user will not likely kill their drives any more quickly than an HDD, particularly since the latter is mechanical, advanced users are often more concerned about this, and will put in the extra effort to increase the lifespan of their SSDs. Typically, this is accomplished through various means to reduce the number of reads and writes to the drive. One method I explored turned out not to be as effective as I’d hoped, but became an interesting learning experience none the less, and may allow for improvements given the right setup.

One of the larger sources of reads and writes to any disk is due to a file system’s journal. Certain file systems, such as NTFS (Windows), Apple File System, and EXT4 (Linux) reserve a portion of a disk to store metadata for any given file. This information can include a file’s creation time, recently accessed time, etc. Such data can prove useful in situations where data recovery and integrity are important, and is thus a common feature. Other file systems, such as FAT can be found on devices where there are limitations (typically in disk space) and do not require a journal, e.g. a USB flash drive. When a journal is present however, this not only (marginally) reduces the available disk space, but may equally increase reads and writes, since with every file access, creation, and deletion, the action is logged.

There is much debate about the best solution to handling journaling with SSDs. Some argue that, so long as TRIM support is enabled correctly, journaling is fine to have. Others recommend (on Linux systems) to set the noatime flag when mounting the system, which disables logging file access time. Though this does reduce the number of writes to disk, there are reports that it may break certain applications. There are still others who recommend disable journaling entirely, though under most circumstances this is not recommended. The approach that I’ve investigated has the potential to work around all of these issues: external journaling.

Unlike most file systems, EXT4 has quite a few options in terms of how the journal is handled. Apart from enabling and disabling this feature, it equally allows using a journal on a separate partition, including ones on different drives. With the PC I’ve most recently build, I use both an SSD and an HDD, and thus theorized that I may be able to have the root directory on the SSD with an EXT4 file system, while its journal will reside on the HDD. The process to set this up is fairly simple, as seen on this guide:

#Create the journal on its own partition

mkfs.ext4 -O journal_dev /dev/journal-device

#Create EXT4 partition, assigning its journal

mkfs.ext4 -J device=/dev/journal-device /dev/ext4-device

This will create a journal on one existing device/partition, and the actual file system on another while using this journal.

The Pitfall

While investigating the means to accomplish this, I began to notice a pattern. Every post I found with regards to external journals did the opposite of my goal: a journal on an SSD with the actual file system on the HDD. To me, this seemed counter intuitive, however there was a fair bit of sense to this. A related post to the previous guide performs some benchmarks on the file system. Their goal, unlike mine, was to improve the performance of an HDD, rather than the longevity of the SSD. By using the SSD as a cache for the journal, the overall throughput of the HDD can be increased significantly. While this does not make much sense with modern hardware, if one possessed an SSD with a very small capacity (e.g. < 10GB), this could be beneficial since it can be difficult to put the entire root directory on a small device. With a larger SSD though, performance is still best when root is directly on it.

The other concern I has was the indication:

..only industrial quality SLC Solid-Stade drives are suitable for external journal…

This lead me to suspect that having an external journal on an HDD may lead to performance problems. With this, I decided to run some benchmarks. Thankfully, they provide the exact tool and command used for their own tests, so it was a simple matter to recreate them.

When running the benchmark with the basic setup of a journaled EXT4 file system directly on the SSD, the benchmark ran for a total of 19m 19.662s, which should be noted is much lower than the presented ~38 minutes best they achieved with an HDD.

When running the benchmark with an external journal on the HDD, while the main file system resides on the SSD, the total time was of 51m 17.13s, which is obviously significantly more slow (roughly 2.5 times). Needless to say, while this method does reduce reads and writes to the SSD, it arguably does not merit the significant performance hit. With all this said, I will end with a list of suggestions:

Recommendations

Although my tests did not go as planned, there are still many things one can do on Linux to help reduce the usage of an SSD, while still reaping its benefits:

• Enable TRIM support
  • There is often a systemd service to enable this
  • May be configured differently depending on the distribution
• Break the system directories into separate partitions
  • /home contains user files, and should generally be kept separate regardless
  • /var can be quite volatile, containing temporary packages, caches, logs, etc. and thus results in more reads/writes
  • /tmp should by default be of type tmpfs (RAM disk), but should at the very least not be used on the SSD
  • swap, when used, may result in large amounts of data read and written, and is typically kept on an HDD regardless
• Create a “quick access” partition on the SSD, if there is enough space
  • Some applications might have slow startup or runtime due to large files being leveraged (e.g. certain games on Steam). These may be kept on the SSD since they are likely used infrequently.
• Do not worry about block alignment
  • Modern Linux file system tools handle this correctly without manual intervention

Oddly enough, I can still recommend using an external journal, however it is only best used with the correct hardware:

• Multiple drives with similar performance ratings
  • e.g. two SSDs
• A small cache drive with higher speeds than the main drive
  • SSD journal with HDD
  • Faster drive (e.g. Optane) journal with an HDD or SSD

If the journal drive is slower, there is little merit to using it separately due to reduced performance.