Hi All - I want to share with you a step-by-step procedure I created after doing hours of research to learn how to correct my SSD drives from the eventual crawl-speed performance they eventually succumb to unless they are 'trimmed'. For Linux, it seems there needs to be a manual intervention to configure a system to maintain SSDs for top performance, at least for some Distros. I tested the following procedures for RHEL 7.6 (desktop enterprise) and OpenSUSE 15.1. This should also work for Fedora. These procedures are for using SSD with LUKS (drive encryption) and LVM partitions. If you don't use encryption or only use primary partitions (instead of logical volume manager), you can skip the parts dealing with lvm.conf and /etc/crypttab.

*****************************updated on 2 June 2019******************************
A responder has provided the following information to add to this post, which is much appreciated:
"RHEL and Fedora are related. openSUSE and SLE are related. openSUSE and RHEL are not related, unless you count that they share rpm as underlying package manager.

"defaults" in fstab is a placeholder. If any other option is included, then its presence is redundant, as all other possible options take the defaults by default. e.g. "/dev/mapper/rhel-root / xfs defaults,noatime 1 1"=="/dev/mapper/rhel-root / xfs noatime 1 1"

In openSUSE, /sbin/shutdown has been a symlink to /usr/bin/systemctl since about 7 years ago (systemd)."
**************************end of 2 June 2019 update***************************************

Here we go.....

Tested for RHEL 7.6 and OpenSUSE 15.1: These are step-by-step procedures for setting up TRIM/fstrim to perform weekly maintenance on SSDs used with LUKS encryption and LVM partitions.

Step A. The following procedures are for extending the life of a SSD.
Ref: https://www.certdepot.net/rhel7-extend-life-ssd/
Others:
https://www.certdepot.net/rhel7-conf...io-schedulers/
https://techgage.com/article/too_tri...is_impossible/
https://lifehacker.com/speed-up-fire...ram-di-5687850
https://www.mahal.org/change-firefox...-save-your-ssd

A.1 Edit the /etc/fstab file and replace all the defaults strings by defaults,noatime. This will stop writing a timestamp every time a file is accessed.

For example:
/dev/mapper/rhel-root / xfs defaults 1 1
becomes
/dev/mapper/rhel-root / xfs defaults,noatime 1 1

A.2 If you have a swap file (can eliminate if you have a lot of ram >2G and don't use hibernate), then put a limit on swap usage. Edit the /etc/sysctl.conf file and paste the following lines:

vm.swappiness=1
vm.vfs_cache_pressure=50

Make the changes active (can be root # or use sudo instead:
# sysctl -p

A.3 Use a SSD-friendly I/O scheduler. Edit the /etc/default/grub file and add elevator=deadline at the end of the GRUB_CMDLINE_LINUX variable.
Make the change active:

Run the following for legacy (non-UEFI boot systems):
# grub2-mkconfig -o /boot/grub2/grub.cfg

For UEFI boot systems:
$ sudo grub2-mkconfig -o /boot/efi/EFI/[redhat or opensuse or fedora]/grub.cfg

Note: pick the operating system you have and eliminate the brackets, so it will look like
$ sudo grub2-mkconfig -o /boot/efi/EFI/opensuse/grub.cfg

A.4 Tweak Firefox to minimize writes to SSD
From browser, go to about:config and edit the following to look as shown

browser.sessionstore.interval 15000000

Note: the default is 15000 (15000ms which is 15 seconds), so adding three 0s increases the time interval for storing sessions on SSD to 1,500,000 ms or 15000s or 250 minutes. Saves 10GB from being written daily. Chrome writes 20 GB daily if not adjusted.

browser.cache.disk.enable false
browser.cache.memory.enable true

Next, create a new preference by right clicking anywhere, hitting New, and choosing Integer. Call the preference browser.cache.memory.capacity and hit OK.

browser.cache.memory.capacity -1 [or some value which is in kb]

Note: type in the number of kilobytes you want to assign to the cache For example, typing 100000 would create a cache of 100,000 kilobytes or 100 megabytes. A value of -1 will tell Firefox to dynamically determine the cache size depending on how much RAM you have.

Step B. The following steps will properly install and configure TRIM for weekly maintenance. Ref (this was a great find): https://cloudnull.io/2017/05/issuing...imers-oh-my-2/

B.1 The first thing to check is that discards are enabled on your encrypted device. If don't see allow_discards on your encrypted device fstrim will not work on any volume within that device.

$ sudo dmsetup table --showkeys

Should see output like the following: luks-4642ef6a-7999-44ce-b70b-ad58daad985d: 0 34803712 crypt aes-xts-plain64 bae889709c0094340aed4dcd0681444c97dc2941c8a41489d8f6c0363d151ee9869551f33523e2daffe4eb0783da887f3378 5e5b6c974257103ef812839fdc1c 0 253:1 4096 1 allow_discards

B.2. If allow_discards shows in B.1 output above, then check to see if fstrim is functioning.

Example fstrim command (success):
If there's no stdout the volume is trimmed meaning it's working.
If there's stdout indicating there's some number of bytes being trimmed, it's working.

$ sudo fstrim /
/: 185.6 MiB (194564096 bytes) trimmed

Example fstrim command (failure):
If the command fails with "operation is not supported" it means its not working and you should continue reading.

$ sudo fstrim /
fstrim: /: the discard operation is not supported

B.3. Assuming fstrim is not successful per B2 above, it’s time to edit the configs.

B.3.1 Edit the file /etc/lvm/lvm.conf and set issue_discards to 1.
Example lvm.conf update:
# Issue discards to a logical volumes's underlying physical volume(s) when
# the logical volume is no longer using the physical volumes' space (e.g.
# lvremove, lvreduce, etc). Discards inform the storage that a region is
# no longer in use. Storage that supports discards advertise the protocol
# specific way discards should be issued by the kernel (TRIM, UNMAP, or
# WRITE SAME with UNMAP bit set). Not all storage will support or benefit
# from discards but SSDs and thinly provisioned LUNs generally do. # If set to 1, discards will only be issued if both the storage and kernel provide support.
# 1 enables; 0 disables.
issue_discards = 1

B.3.2 Edit the file /etc/crypttab and ensure 'none discard' is set as an option. If ‘none’ is missing from the crypttab file, add it so it looks like the following (otherwise an error message will occur upon bootup saying ‘discard’ is not a valid argument and it becomes ignored.

Example crypttab update:
luks-ec95d8cd-620d-44af-acd1-5adfef220a84 UUID=ec95d8cd-620d-44af-acd1-5adfef220a84 none discard
luks-4642ef6a-7999-44ce-b70b-ad58daad985d UUID=4642ef6a-7999-44ce-b70b-ad58daad985d none discard
luks-f4e911b7-5311-4605-a105-64e695dbca77 UUID=f4e911b7-5311-4605-a105-64e695dbca77 none discard
luks-04f5fd5e-396b-49c5-a328-284cfa3d0e0e UUID=04f5fd5e-396b-49c5-a328-284cfa3d0e0e none discard

B.3.3 Update the initrd and reboot.

$ sudo mkinitrd –force
$ shutdown -r now

With the system rebooted you should see the "allow_discards" enabled on your encrypted volumes.

Example encrypted device with the discard option:

$ sudo dmsetup table --showkeys

cr_ata-XXX-YYY-partZ /dev/disk/by-id/ata-XXX-YYY-partZ: 0 12345 crypt aes-xts-plain64 XXYYZZ 0 8:3 4096 1 allow_discards

Step C. Enable an fstrim timer.

To ensure you're system is trimmed regularly enable an fstrim timer. On most Linux system with systemd the fstrim.timer is already present, it's just not enabled. If you don't have an fstrim timer already available then the procedure at the end can be used to install it.

With the fstrim.timer ready, enable it systemctl enable fstrim.timer and verify it's running by checking the status, systemctl status fstrim.timer.

$ sudo systemctl enable fstrim.timer
$ sudo systemctl status fstrim.timer

Should see an output like:

● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Sat 2019-06-01 08:56:02 EDT; 2h 0min ago
Docs: man:fstrim

Jun 01 08:56:02 bluewave systemd[1]: Started Discard unused blocks once a week.


Done!
First manual trim job: $ sudo fstrim -a -v
All others can be left to the weekly timer.

Step D. If you don't have an fstrim timer already available then use this procedure to install it.

D.1 Create the file /etc/systemd/system/fstrim.timer.

[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

D.2 Create the file /usr/lib/systemd/system/fstrim.service.

[Unit]
Description=Discard unused blocks

[Service]
Type=oneshot
ExecStart=/usr/sbin/fstrim -av

D.3 Reload the systemd daemon, systemctl daemon-reload.

$ sudo systemctl daemon-reload

D.4 Return to Step C above.

You can make this more readable with code tags

Like this...
Also I think this better belong in a blog and LinuxQuestions have a blogging feature https://www.linuxquestions.org/questions/blog/

Thank you ugjka. I blogged it with some tags.
Anthony

You don't have to go crazy over preventing writes to an SSD much any more. I have 2 Samsung 850 Pro drives, each about 3 years old with about 4k hours on each. I have done nothing special other than enable trim on my file systems (UFS2). I certainly have not changed FF to minimize writes but it is, obviously possible. The quality of SSDs these days is very good if you buy quality units to begin with.

Hello sevendogbsd

Thank you for the update. I did this procedure for a Samsung 840EVO and a Samsung 840PRO, and noticed a significant improvement in speed after having used these drives for years without trim/fstrim.

Maybe in a BSD OS with UFS the trim/fstrim is no longer needed? Maybe still beneficial in some non-BSD OS? I run OPNSense with FreeBSD 11.2 in a Geom mirror firewall router and didn't bother checking into trim for that - it seems to run fine.

Regards
Anthony

Good question: trim probably speeds things up but I don't understand the mechanics of it, just that it is desirable. I have read, from the creator of the ext4 file system, that continuous trim via (discard) in fstab is not desirable any longer. On FreeBSD anyway, enabling trim at the file system level does automatic trimming and you don't have to do it manually. How that works or the frequency, I have no idea. On Linux, you can either do it manually or let systemd do it, if you have a systemd distro, obviously, as you have posted . I can't speak to OpenBSD or NetBSD as I have never used those.

We had this discussion about SSD life on the FreeBSD forums and after several users posted the output of smartctl, we came to the conclusion that most SSDs wear pretty well. One user had many more hours on his SSD than I yet the remaining life was considerable. Unfortunately, I don't think the Samsungs report life remaining (I can't remember the parameter value for this).

I don't think anything you posted in the blog is harmful in any way, it's good info, I just think after reading a bunch on this issue, SSDs appear to be extremely solid now and we probably don't have to worry about them much. I seem to remember reading something about wiping software though (file shredding) that stated you should not run it on SSDs, or that it was not effective, I can't remember which.

Back up your data, of course .

Hi sevendogsbsd

Thanks for the additonal discussion. I'm using two systemd Linux distros that don't do trim unless manually configured to enable it. I run fstrim on a weekely timer, and was also aware that discard run from /etc/fstab is not the proper way to do it (per the Linux community anyway) because it runs trim continuously - which is not good for the SSD. The instructions I gave are for the weekly run of trim via fstrim only, so no chance of someone accidently going the fstab/discard path by those instructions. I read other OSs have this functionality active by default in some manner, like Windows and Mac OS, Ubuntu maYBE, and seems like BSD as well. I bought a couple of books on BSD, both by Michael W Lucas: Absolute FreeBSD, Absolute OpenBSD. Time to delve into a new nix OS. I'm impressed with them so far. BSD predates Linux, and Linux 'borrowed' from it.

And I always back up my data

Anthony

1 members found this post helpful.