SSD

This article Solid State Drives) on Linux.]]

It presumes the user has obtained knowledge of setting up, partitioning, and formatting mechanical hard drives.

Introduction
Term Solid State Drive is commonly used for flash-based block devices. Compared to conventional HDD the flash-based technology offers quicker access time, lower latency, silent operation and more. However, the flash-based technology brings several issues which require specific system setup.

Dealing with empty blocks
Generally, traditional filesystems don't erase deleted data blocks but only flags them as such. Due to nature of flash memory cells any write operation has to be done to empty cells only. Thus writing to physically non-empty cells, flagged as deleted by a filesystem, requires their erasure which makes the operation slower than writing to empty cells. This problem is further amplified by hardware limitations.

For modern kernels it is possible to hint the deleted (not-used) data blocks to SSD. The described mechanism is called discard. Names of implementations differ — TRIM for ATAPI and UNMAP for SCSI. Filesystem's support is required in order to use discard. Majority of modern filesystems (like Ext4, XFS or Btrfs ) support discard. Also there are filesystems developed primarily for flash-based devices, such as F2FS.

There are two basic approaches to issue the discard command — using   option  for continuous discard or periodic calls of  utility.

Slowing wear out
Each write operation performed on a NAND flash cell causes its wear. This fact limits the SSD lifespan. The cell endurance varies with used technology. On the other hand, read operations are straightforward and do not cause cell wear.

A basic method increasing SSD lifespan is to uniformly distribute writes across all the blocks. This method is called wear leveling and is deployed via SSD firmware.

From system point of view, it is appropriate to generally reduce amount of writes.

Discard support
Device's support of discard should be verified before performing any form of discarding.

It is possilbe to use utility from :

A device supporting discard has non-zero values of  (discard granularity) and   (discard max bytes). In this example listing the supports discard and  does not.

Partitioning
See Handbook.

LVM
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 utility:

Alternatively, there is a discard option in 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.

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

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:

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

To evaluate if TRIM is enabled on a LUKS device, you can check if the output of the following command contains the string :

Formatting
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. https://raid.wiki.kernel.org/index.php/RAID_setup#ext2.2C_ext3.2C_and_ext4_.282011.29

http://blog.nuclex-games.com/2009/12/aligning-an-ssd-on-linux/

The modern FAQ found on the Arch wiki too:

https://wiki.archlinux.org/index.php/SSD

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

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:

known erase block sizes

 * crucial m500 240G; stride and stripe width is 2048KB


 * SanDisk z400s; stride an stripe width is 4096KB

blkdiscard
If you are formatting a previously used device and your preferred does not support bulk discards when creating the filesystem, you can use  (from  or later) before creating the filesystem.

Mounting
For rootfs it is usually recommended to periodically use utility. Using   option results in continuous discard that could potentially cause degradation of older or poor-quality SSDs.

The following command can be used manually or be setup as a periodic job to run once a week :

For mount points with a low amount of disk writes occurring on a SSD it should be safe to use   option in. Also it is recommended to use the option when maintaining performance is required.

Given the considerations above, a discard-enabled could look like this:

Once the has been modified, remount all filesystems mentioned there via:

Periodic fstrim jobs
There are multiple ways how to setup a periodic block discarding process. As of 2018, the default recommended frequency is once a week.

cron
Run on all mounted devices that support discard weekly:

#Mins Hours  Days   Months  Day of the week   Command 15    13     *      *       1                 /sbin/fstrim --all

Similarly, it is possible to run only for a selected mount point:

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

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

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


 * Distribution independent script (developed on a 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, or any other defined directory and if it should make an entry into.
 * Checks if the kernel meets the requirements, the filesystem is able to and if the SSD supports trimming.

systemd timer
When running a system with systemd version 212 or newer, a persistent systemd timer can be created that will run weekly. Thanks to timer's persistency it will be issued immediately if a scheduled run was missed.

Two systemd unit files need to be created in the directory:

Service called  which actually executes the :

Timer which wakes up the  service weekly:

Make sure the permissions are correct:

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

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

Also the command can be used to make sure the timer runs successfully.

Reducing amount of writes
The flash-based SSDs have a limited write lifetime - the number of writes performed. Thus when using a SSD, administrators generally want to reduce the amount of writes.

Portage TMPDIR on tmpfs
When building packages via Portage it is possible to perform the operations on tmpfs and get the tmpfs' benefits. See Portage TMPDIR on tmpfs guide.

Temporal files on tmpfs
It is possible to mount desired mount points as tmpfs. Since tmpfs stores files in volatile memory all the I/O operations directed to the given mount points are not performed on the solid state disk. This reduces the amount of writes and also improves performance.

This is an example of both and  being mounted as tmpfs:

XDG cache on tmpfs
When running a Gentoo desktop, many programs, using X Window System (Chromium, Firefox, Skype, etc.) are making frequent disk I/O every few seconds to cache.

The cache directory location usually complies to XDG Base Directory Specification, namely to the XDG_CACHE_HOME environment variable. The default cache location is, which is usually mounted on a hard drive and could be moved to tmpfs.

To remap the cache directory location create file :

Web browser profile/s and cache on tmpfs
The web browser profile/s, cache, etc. can be relocated to tmpfs. The corresponding I/O associated with using the browser gets redirected from the SSD drive to tmpfs' volatile memory, resulting in reduced wear to the physical drive and also improving browser speed and responsiveness.

You can relocate the browser components mentioned above with the utility :

Next add the users whose browser/s profile/s will get symlinked to a tmpfs or another mountpoint in the variable :

Finally, close all the browsers, start and enable the daemon.

On systemd:

On OpenRC:

Now it is possible to view all symlinks by printing the status of the started daemon:

More info about Profile-Sync-Daemon can be found on Arch's wiki.