SDB:SSD performance

openSUSE Support Database

Portal - SDB Categories - How to write an article

Tested on openSUSE

Recommended articles

SSD discard (trim) support

Related articles

This article explains how to optimize openSUSE for an SSD.

Situation

Your brand new computer has an SSD drive. You might not want to wear it out too soon and you'd like to profit as much as you can from its performance. So, what file system should you use? Anything else? You'll find it here.

Maximize performance & durability

This article describes several choices you have to make:

TRIM

For more information about TRIM please see the wiki article on SSD Discard Support.

To be noted, contrary to SSD, "discard" should not be applied to NVMe SSD, as stated on ArchWiki using periodical or manual Trim instead for NVMe SSD. openSUSE Tumbleweed already takes care of this if it is installed on a NVMe SSD. The support could be confirmed with following command,

$ systemctl status fstrim
● fstrim.service - Discard unused blocks
   Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
   Active: inactive (dead)

Intel SSD

There is a bug in old Intel SSD firmware, that will cause stalls when the smartd daemon is running, which is enabled by default. To solve it, upgrade your drive's firmware from [1]

Filesystems

The file systems which work best with SSD drives are BTRFS and EXT4. BTRFS filesystem even has an option named ssd used within /etc/fstab for partitions on a SSD.

In this article we assume /dev/sda (here, a means device 0) is your SSD (it could be /dev/nvme0n1 (here, 0 means device 0) for a NVMe SSD).

create TMPFS filesystems

It is highly recommended to put the most volatile parts of your data on a TMPFS - this especially includes the /tmp directory. This directory only contains temporary files which are deleted upon reboot. Having this in memory is an excellent way to save your SSD some work. For openSUSE Tumbleweed only, since Snapshot Version 20200806 fresh installations use tmpfs for /tmp by default. For prior installations, or for Leap, tmpfs for /tmp needs to be enabled manually, as below. Note that if you keep your system running for a long time, the size of this directory (hence its memory usage) can balloon quite a bit. It is recommended to log out of your DE, remove the content, and log in again if you're experiencing memory pressure.

Mount /tmp in a tmpfs filesystem:

# ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/

This will create the /tmp folder in memory on a fresh boot.

Tumbleweed and Btrfs

When Btrfs filesystem is used for root partition on Tumbleweed, the default (as of snapshot 20170403) /tmp is mounted on a subvolume of / partitioin. It has an entry in /etc/fstab looking like (content enclosed with __ and __ themselves are description replacing real content on purpose),

UUID=__string of UUID__ /tmp btrfs subvol=@/tmp 0 0

Under this situation, previously described systemd method might not be able to change /tmp from subvol=@/tmp to a tmpfs filesystem. Then, one could put a # before this line and add another line for mounting the created TMPFS as /tmp. Such as,

#UUID=__string of UUID__ /tmp btrfs subvol=@/tmp 0 0
#__other subvols__
tmpfs   /tmp            tmpfs   uid=root,gid=root,mode=1777,size=512M 0 0

where size=512M is an option to set the maximum capacity of /tmp to be 512MiB. One could also use size=2G for 2GiB, or even relative size of size=25% of total size of physical memory considering the total physical memory size available.

Other changes

Some other changes you can do

noatime for EXT4

A change you should do in /etc/fstab is to make sure that your SSD has the noatime option:

 /dev/sda1    /  ext4   noatime,defaults  0       1

noatime might break some backup tools; using relatime could solve that.

Tuning the kernel (I/O Scheduler)

Check the scheduler first. For `sda` device,

$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

Here, 'cfq' is active (indicated by the `[ ]`). For NVMe SSD device,

$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

'none' is selected and this means no scheduler used. If other device is involved, change the path correspondingly.

It is recommended that you change the default scheduler from cfq to deadline but only for non-rotating disks.

# vi /etc/udev/rules.d/60-sched.rules

#set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

Note: Based on a test reported by Phoronix, 'none' is the best in none, mq-deadline, kyber and bfq for NVMe SSD.

readahead

You may disable readahead as it is quite useless on SSD's with their minimal seek times.

# systemctl disable systemd-readahead-collect.service

# systemctl disable systemd-readahead-replay.service

And done.

Disable Swap on SSD

Most modern computers with 2GB+ of RAM will rarely use swap space unless they need it to store data on the drive (such as the hibernate feature). The following is a tweak that will reduce the amount of writes to the swap area to help prevent the SSD from wearing out.

# echo 1 > /proc/sys/vm/swappiness

Or if you wish to make it permanent you can add the following lines to /etc/sysctl.d/99-sysctl.conf

vm.swappiness=1
vm.vfs_cache_pressure=50

Even more

Flash memory is managed in blocks, larger than the 512 byte units that partitions are measured in. With default linux tools (but there should no longer be an issue with openSUSEs newer enough, 12.2 or above), you'll surely align the filesystem in such a way that it generates unnecessary IO because every time you write data it touches two instead of one block. You can solve this by aligning the partitions and the filesystems on them to larger blocks than 512 bytes and making sure they start at 0.

However it is quite a procedure and you'll only do it on a new SSD. In the links below you can find information on how to do it: