From Gentoo Wiki
Jump to: navigation, search
Article status
This article needs wikification.
This article is a stub. You can help by expanding it.

This article describes how to set up SSDs (Solid State Drives) on Linux. It presumes the user has obtained knowledge of setting up, partitioning, and formatting mechanical hard drives.



The -o discard option on a rootfs mount should not be used. discard is the "TRIM" command that tells the SSD to do its magic. Having discard running constantly could potentially cause performance degradation on older SSDs. Modern SSDs use discard by default. Rather the following command can be used manually or be setup as a cron job (see below) to run twice a day, which should suffice for the rootfs:

root #fstrim -v /

On a btrfs system, running the fstrim command on any mounted subvolume will perform the TRIM command on the device.

Mount point

Situations with a low amount of disk write occurring on an SSD can use the discard mount option in /etc/fstab. In a high-write situation, such as having a database on an SSD, it is better to use TRIM commands rather than the discard mount option.

After hardware installation


See Handbook.


LVM aligns to MiB boundaries and allows discards by default. No special configuration is required.

In order to TRIM all unused space in the VG use the blkdiscard utility:

root #lvcreate -l100%FREE -n trim yourvg
root #blkdiscard /dev/yourvg/trim
root #lvremove yourvg/trim

Alternatively, there is a discard option in lvm.conf which makes LVM discard entire LV on lvremove, lvreduce, pvmove and other actions that free physical extents (PE) in a VG. However, enabling it will immediately render the system unable to undo any changes to the LV layout.

FILE /etc/lvm/lvm.conf
devices {
  issue_discards = 1


For TRIM to work on encrypted LUKS devices, they have to be opened with the --allow-discards option.

root #cryptsetup luksOpen --allow-discards /dev/thing luks

When root-device exists on LUKS, enabling TRIM depends on the Initramfs implementation. When using genkernel for creating your initramfs, pass the following kernel option:

FILE /etc/default/grub

When using dracut for creating the initramfs, pass the following kernel option:

FILE /etc/default/grub


If you can find your erase block size, you can add some extended attributes that may help performance. For software raid, you really should know the erase block size. Consider this information when making your purchase. Regardless of whether you're using RAID or not, setting extended values is known to be beneficial.

The modern FAQ found on the Arch wiki too:

Without knowing the erase block size

  1. Formatting the rootfs partition /dev/sda3:
  2. Using 4096 byte blocks by default aligns the SSD for writes (see [defaults] section of /etc/mke2fs.conf and also
  3. man mkfs.ext4 about "-b block-size" and "-T usage-type[,...]" inside it):
root #mkfs.ext4 /dev/sda3

With knowing the erase block size | this info can be outdated

  1. Formatting the rootfs partition /dev/sda3:
  2. Using 4096 byte blocks aligns the SSD for writes;
  3. Using ERASE_BLOCK_SIZE / 4 as the stride and stripe width size;
  4. In this example, OCZ Vertex drives have 512 kibbibyte -
  5. Erase Block size, therefore stride/stripe-width = 512/4 = 128:
root #mkfs.ext4 -E stride=128,stripe-width=128 /dev/sda3
known erase block sizes
  • crucial m500 240G; stride and stripe width is 2048KB
Page size is 16KB, there are 512 pages per Block.[1] 16KB * 512 = 8192KB for block size. Block erase size = block size. 8192KB / 4 = 2048KB for stride and stripe width size.
  • SanDisk z400s; stride an stripe width is 4096KB
According to Dutch customer care service from SanDisk the block erase size = 16MB.


If you are formatting a previously used device and your preferred mkfs does not support bulk discards when creating the filesystem, you can use blkdiscard (from sys-apps/util-linux-2.23 or later) before creating the filesystem.


Given the considerations above, either add something similar to this:

FILE /etc/fstab
/dev/sda3          /          ext4          defaults,relatime,discard          0 1


FILE /etc/fstab
/dev/sda3          /          ext4          defaults,relatime                  0 1

When choosing the latter, see the cron section below to automate TRIM on the drive.

Once /etc/fstab can been modified, run the following command to have the drive mounted:

root #mount -a

In the same way, the discard mount option can be added to the swap line in fstab too. The following example shows SSD disk swap can be parallelized with SATA disk swap:

FILE /etc/fstab
/dev/sda2          none           swap         sw,pri=3,discard          0 0
/dev/sdb2          none           swap         sw,pri=3                  0 0

Once the swap has been configured in fstab, run the following command to make swap available:

root #swapon -a



Run fstrim -v / from cron twice a day to automatically do "discard":

  #Mins  Hours  Days   Months  Day of the week   command
  15     1,13   *      *       *                 /sbin/fstrim -v /

There is also a semi-automatic cronjob available on GitHub called SSDcronTRIM which has the following features:

  • Distribution Independent script (developed on my Gentoo system).
  • The script decides every time depending on the disk usage how often (monthly, weekly, daily, hourly) each partition has to be trimmed.
  • Recognizes if it should install itself into /etc/cron.{monthly,weekly,daily,hourly}, /etc/cron.d or any other defined directory and if it should make an entry into crontab.
  • Checks if the kernel meets the requirements, the filesystem is able to and if the SSD supports trimming.
  • Simply install it by running it once without any option and uninstall it with the -d option

Future version should implement:

  • Use of nice and ionice to let trimm only run when the disc is not busy.
  • Overgive options to fstrim (e.g. '-m 1M')
  • support for encrypted filesystem (LUKS)

fstrim systemd timer

When running systemd, a timer can be created that will run fstrim every 12 hours.

Two files need to be created in the /etc/systemd/system directory:

FILE /etc/systemd/system/fstrim.service
Description=Runs fstrim on all mounted devices that support TRIM

ExecStart=/bin/sh -c '/sbin/fstrim -a'
FILE /etc/systemd/system/fstrim.timer
Description=Run fstrim.service every 12 hours



Make sure the permissions are correct:

root #chmod 644 /etc/systemd/system/fstrim.*

Tell systemd to reload its unit files, then enable it:

root #systemctl daemon-reload
root #systemctl enable fstrim.timer

It is now possible to see if it has been run and when the next time it will be ran by using list-timers:

root #systemctl list-timers
NEXT                         LEFT     LAST                         PASSED    UNIT                         ACTIVATES
Sun 2017-01-15 07:07:48 PST  11h left Sat 2017-01-14 19:03:26 PST  25min ago fstrim.timer                 fstrim.service
Sun 2017-01-15 19:16:26 PST  23h left Sat 2017-01-14 19:16:26 PST  12min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

This will run fstrim twice a day, and also run it if it was missed. The journalctl command can be used to make sure the timer runs successfully.


If your computer turned off when cron scheduled its job, fstrim would not be called at all. You can install fstrimDaemon to solve this problem.

Temporal files to TMPFS

When using an SSD, administrators generally want to reduce the amount of writes performed. You can mount your desired mountpoints into a TMPFS for reduce the I/O to the disk (and improve performance)

this is an example of /tmp and /var/tmp on TMPFS but you must study all your actions and your convenience

# temporal mountpoints on TMPFS
tmpfs           /tmp            tmpfs           size=16G,noatime        0 0
tmpfs           /var/tmp        tmpfs           size=1G,noatime         0 0

Remember that all data in TMPFS will be loss after reboot or shutdown


On Gentoo, Portage is a huge source of writes, and putting these writes into system memory rather than a disk is beneficial. If you have more than 8GB of ram you may want to consider using tmpfs, which is a way to dedicate some system memory to storage on a temporary basis. It is generally advised to not use more than half of the available system memory for tmpfs.

For the next example, presume the system has 12GB of memory and the user would like to allow up to 6GBs for tmpfs. Edit /etc/fstab and add:

tmpfs			/tmp		tmpfs		size=6G,noatime 	0 0

After the fstab entry is set, tell Portage to use the above location to compile temporary space. This is done in /etc/portage/make.conf:

# This may fail on large compiles unless you have greater than 20GB of system memory is available. Scratch space for Libreoffice can exceed 8GB; compile will fail if it runs out of space.
# RAM used by [[Portage_TMPDIR_on_tmpfs|tmpfs]] is freed back to the pool when it is no longer in use, so when using Portage or other software that uses /tmp there should be a huge performance gain.

you can explain your information on an specific gentoo's wiki article: Portage_TMPDIR_on_tmpfs

XDG cache

When running Gentoo on desktop, many programs, using X windows systems (Chromium, Firefox, Skype, etc.) are making frequent disk I/O every few seconds to cache. Default cache directory is ~/.cache, which is on hard drive and should be moved to tmpfs.

Create the file /etc/profile.d/ and add the following lines to it:

FILE /etc/profile.d/

export XDG_CACHE_HOME="/tmp/${USER}/.cache"

Do not forget to run env-update && source /etc/profile:

root #env-update && source /etc/profile
The above command only updates the variables in the current terminal, new consoles, and their children. Thus, if the user is working in X11, he needs to either type
user $source /etc/profile
in every new terminal opened or restart X so that all new terminals source the new variables. If a login manager is used, it is necessary to become root and restart the /etc/init.d/xdm service.

With above change, auto unlocking the gnome keyring didn't work anymore. /var/log/messages said the following:

  May  5 10:02:52 localhost gnome-keyring-daemon[5561]: couldn't bind to control socket: /home/david/.cache/keyring-hRt5QC/control: No such file or directory

Browser profile/s and cache to RAM or HDD

Since the profile/s, browser cache*, etc. are relocated into TMPFS (RAM disk) or another mount point into an HDD, the corresponding I/O associated with using the browser is also redirected from the physical drive to RAM, thus reducing wear to the physical drive and also greatly improving browser speed and responsiveness.

You can move them with the utility www-misc/profile-sync-daemon

root #emerge --ask www-misc/profile-sync-daemon
www-misc/profile-sync-daemon version 6 or greater requires systemd

Add that users whose browser/s profile/s will get symlinked to a TMPFS or another mountpoint in the value USERS=

FILE /etc/psd.conf
USERS="user user2 root"

close all the browsers, start the daemon and enable it

root #systemctl enable psd && systemctl start psd

you can view all symlinks viewing the status of the daemon since started

root #psd p

More info about Profile Sync Daemon on

See also

  • HDD – describes the setup of an internal SATA or PATA (IDE) rotational hard disk drive.
  • NVMe - Non-Volatile Memory Express.