Any steps needed to setup TRIM for SSD

[Return2Kubutnu]

Hi all, just wondering if everything was taken care of, I looked in etc/fstab and see no mention of "noatime" or anything else. I know I can always do a manual trim but maybe a weekly or monthly one might be a good idea, please could someone tell me what is the default setting in Kubuntu 18.04 for TRIM on SSDs?? greatly apreciated, thank you

[jglen490]

Here's an interesting comment on TRIM, and why it's not enabled by default in Ubuntu. It does suggest running TRIM via fstrim in a chron job.

https://www.howtogeek.com/176978/ubu...e-it-yourself/

[jglen490]

So I got a little more curious about fstrim, and found that the cron job for running fstrim ("on supported filesystems") is already setup on my 16.04.4 and that fstrim was installed with util-linux:

john@John-Desktop:~$ dpkg -L util-linux|grep fstrim
/etc/cron.weekly/fstrim
/sbin/fstrim
/usr/share/man/man8/fstrim.8.gz
/usr/share/doc/util-linux/examples/fstrim.timer
/usr/share/doc/util-linux/examples/fstrim.service
/usr/share/bash-completion/completions/fstrim

Old guy learns something again!

[GreyGeek]

That howtogeek info is five years old. Btrfs in 16.04 is currently at the 4.4 version. The latest version is 4.17.
The Btrfs Wiki FAQ states:

Does Btrfs support TRIM/discard?

There are two ways how to apply the discard:

• during normal operation on any space that's going to be freed, enabled by mount option discard
• on demand via the command fstrim

"-o discard" can have some negative consequences on performance on some SSDs or at least whether it adds worthwhile performance is up for debate depending on who you ask, and makes undeletion/recovery near impossible while being a security problem if you use dm-crypt underneath (see http://asalor.blogspot.com/2011/08/t...-problems.html ), therefore it is not enabled by default. You are welcome to run your own benchmarks and post them here, with the caveat that they'll be very SSD firmware specific.


The fstrim way is more flexible as it allows to apply trim on a specific block range, or can be scheduled to time when the filesystem perfomace drop is not critical.

Making a cron task out of "fstrim -v /" seems to be the common solution because the kernel version of fstrim isn't very good.

[Return2Kubutnu]

Thanks guys, I forgot to mention I use ext4...but will take a look and am not too fussed about a cron job because I can just do a sudo fstrim -v / once every couple of weeks or something manually. I did read some of the many debates about trim being applied too frequently, I think it was when (until recently) I was using Manjaro...I wont bother setting up a cron, but by the looks of it there is already one as per jglens reply but he is mentioning 16.04...I was just wondering about 18.04 and Kubuntu specifically...thanks for replies

Looks like systemd is doing somethig with trim here is my output

nexus6@Bladerunner:~$ dpkg -L util-linux|grep fstrim
/lib/systemd/system/fstrim.service
/lib/systemd/system/fstrim.timer
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man8/fstrim.8.gz

hmm, I'm wondering about what the "8" means

[GreyGeek]

https://askubuntu.com/questions/1025...-file-with-man

[Rod J]

I followed most of the advice on this page https://sites.google.com/site/easylinuxtipsproject/ssd to set up trim as a daily cron job.

The advantages of running it daily is that it only takes a few seconds (on my system anyway) to complete.

Here is the syslog output of the trim done tonight after a fresh restart. It took longer than usual (four seconds) and seems to have trimmed most of the system partition. Usually, it just trims a few Gb and the process takes no more than two seconds.

Jun 25 00:00:02 Core-i5 systemd[1]: Starting Discard unused blocks...
Jun 25 00:00:06 Core-i5 fstrim[4303]: /: 44.6 GiB (47822770176 bytes) trimmed

On my previous install (Kubuntu 14.04) I had trim set to run every start/restart and it never seemed to cause any problems. My Crucial MX550 SSD is about two and a half years old now.

[Return2Kubutnu]

Thanks very much for replies

[GreyGeek]

I followed most of the advice on this page https://sites.google.com/site/easylinuxtipsproject/ssd to set up trim as a daily cron job.

The advantages of running it daily is that it only takes a few seconds (on my system anyway) to complete.

Here is the syslog output of the trim done tonight after a fresh restart. It took longer than usual (four seconds) and seems to have trimmed most of the system partition. Usually, it just trims a few Gb and the process takes no more than two seconds.

Jun 25 00:00:02 Core-i5 systemd[1]: Starting Discard unused blocks...
Jun 25 00:00:06 Core-i5 fstrim[4303]: /: 44.6 GiB (47822770176 bytes) trimmed

On my previous install (Kubuntu 14.04) I had trim set to run every start/restart and it never seemed to cause any problems. My Crucial MX550 SSD is about two and a half years old now.

4 seconds. Not too shabby. Are you using EXT4?

[jglen490]

Thanks guys, I forgot to mention I use ext4...but will take a look and am not too fussed about a cron job because I can just do a sudo fstrim -v / once every couple of weeks or something manually. I did read some of the many debates about trim being applied too frequently, I think it was when (until recently) I was using Manjaro...I wont bother setting up a cron, but by the looks of it there is already one as per jglens reply but he is mentioning 16.04...I was just wondering about 18.04 and Kubuntu specifically...thanks for replies

Looks like systemd is doing somethig with trim here is my output

nexus6@Bladerunner:~$ dpkg -L util-linux|grep fstrim
/lib/systemd/system/fstrim.service
/lib/systemd/system/fstrim.timer
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man8/fstrim.8.gz

hmm, I'm wondering about what the "8" means

Based on your dpkg list, it would appear that 18.04 does not set up the weekly cron as it did in 16.04. I also use ext4 and I do not currently have an SSD on my desktop platform. So, the logic then in 16.04 was not based the presence of an SSD. It certainly does not hurt for cron to run the job, but it probably does nothing - on my system. So you should be able to set up a daily or weekly cron of fstrim and take care of busness! The man pages for fstrim will have a good explanation of the uses of fstrim.

[oshunluvr]

I guess it depends on the installation, but here I have this file; /etc/cron.monthly/fstrim
and it contains

#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true

This and the other files in there are run by anacron monthly.

[Rod J]

4 seconds. Not too shabby. Are you using EXT4?

For some reason Thunderbird placed several of my forum notification emails into the Spam folder and I missed this one.

Better late than never I guess ... yes I'm still using EXT4.

[SpecialEd]

It seems Kubuntu 18.04 also automatically added fstrim.service to my system.

specialed@specialed-Aspire-VN7-791:~$ dpkg -L util-linux|grep fstrim
/lib/systemd/system/fstrim.service
/lib/systemd/system/fstrim.timer
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man8/fstrim.8.gz

This runs every time I boot the machine. The problem is it adds 15 seconds to my boot time.

specialed@specialed-Aspire-VN7-791:~$ systemd-analyze blame         
        15.071s fstrim.service
         7.953s NetworkManager-wait-online.service
         1.783s apt-daily-upgrade.service
         1.324s networkd-dispatcher.service
         1.192s gpu-manager.service
         1.154s snapd.service
          748ms mpd.service
          660ms NetworkManager.service
          647ms apt-daily.service
          612ms motd-news.service
          538ms colord.service
          520ms dev-sdb1.device
          470ms systemd-user-sessions.service
          403ms virtualbox.service
          263ms udisks2.service
          217ms systemd-logind.service
          200ms ModemManager.service
          183ms systemd-resolved.service
          180ms grub-common.service
          172ms systemd-timesyncd.service
          148ms systemd-udevd.service
          147ms apparmor.service
          129ms systemd-journal-flush.service
          128ms systemd-rfkill.service
          127ms upower.service
          123ms wpa_supplicant.service
          110ms accounts-daemon.service
           93ms alsa-restore.service
           77ms keyboard-setup.service
           76ms apport.service
           70ms systemd-udev-trigger.service
           68ms plymouth-quit.service
           65ms rsyslog.service
           56ms polkit.service
           55ms thermald.service
           53ms swapfile.swap
           45ms systemd-journald.service

I'd prefer to remove the service on boot and change it to a cron job or even do it manually. Also the 7.953s NetworkManager-wait-online.service adds almost 8 seconds to my boot times too. Can I remove that? If so how?

[Thomas00]

It seems Kubuntu 18.04 also automatically added fstrim.service to my system.
This runs every time I boot the machine. The problem is it adds 15 seconds to my boot time.

What does systemctl status fstrim.timer say?
I have done quite a few fresh installs of 18.04 and 18.10 recently and trim has always been setup to run weekly by default.
Unless you boot only once a week it shouldn't show up in your systemd -analayze report I guess?

● fstrim.timer - Discard unused blocks once a week
 Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
 Active: active (waiting) since Mon 2018-11-12 08:48:47 CET; 26min ago
Trigger: Mon 2018-11-19 00:00:00 CET; 6 days left
   Docs: man:fstrim

Nov 12 08:48:47 hermes systemd[1]: Started Discard unused blocks once a week.

[mr_raider]

It should run once a week. If it's running on every boot, that means the trim is failing.

Btrfs has issues with TRIM commands running slow.

Sent from my ONEPLUS A5010 using Tapatalk