Home Wiki > SDB:SSD performance
Sign up | Login

The english openSUSE wiki has been moved and updated recently. If you encounter any issue, please let us know by mail to admin@opensuse.org.

SDB:SSD performance

tagline: From openSUSE

Tested on openSUSE Recommended articles Related articles

Icon-manual.png Icon-help.png

This article explains how to optimize openSUSE for an SSD.


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:


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]


The file systems which work best with SSD drives are BTRFS and EXT4. However, BTRFS is still experimental, so Ext4 is the safest choice.

However if you intend to run Tumbleweed the kernels newer than the default in openSUSE 11.4 will most likely start to offer better performance on BTRFS than Ext4 while this file system matures. 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. 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:

# mkdir -p /etc/systemd/system/local-fs.target.wants
# ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/local-fs.target.wants/tmp.mount

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

On openSUSE 12.2 the procedure should be a bit different:

Start by creating directory(ies) for custom configuration, e.g.

# mkdir -p /etc/systemd/system/local-fs.target.wants

as above.
Create unit file for systemd (using vi or your preferred editor):

# vi /etc/systemd/system/tmp.mount

and copy-paste this text (to paste in vi: i followed by Shift-Ins), then save (in vi: :wq)

#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

Description=Temporary Directory


Finally create the symlink, similarly like above:

# ln -s /etc/systemd/system/tmp.mount /etc/systemd/system/local-fs.target.wants/

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

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"


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


Even more

Flash memory is managed in blocks, larger that the 512 byte units that partitions are measured in. With default linux tools (but there should no longer 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 the 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:

See also

Related articles

External links