Status indication TRIM

General system Newbie
1

Today I have checked the status of TRIM with
systemctl status fstrim.timer
to display the status:

[uwe@HAL ~]$ systemctl status fstrim.timer
● 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 2022-07-02 12:06:10 CEST; 9h ago
Until: Sat 2022-07-02 12:06:10 CEST; 9h ago
Trigger: Mon 2022-07-04 00:39:35 CEST; 1 day 2h left
Triggers: ● fstrim.service
Docs: man:fstrim

Jul 02 12:06:10 HAL systemd[1]: Started Discard unused blocks once a week.

All is well, but I am a little confused by the display

vendor preset: disabled

Can this be changed, does it need an additional package?

2

That only means that when a service is initially installed in the system, it is disabled by default.
It is then up to the user to enable and start it.

You don’t need to add anything more.

3 Likes
3

It sounds to me that the provider of my SSD, to which TRIM is applied here, cannot be read. My English is not good enough that I understand this without a translator. So what service are we talking about here specifically?

4

Oh, Sorry, my bad!
This was a timer. But the point is valid for both timers and services.

I am not sure if I follow you here.

Also check if your SSD supports TRIM:

Warning: Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!

To verify TRIM support, run:

$ lsblk --discard

And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.

Alternatively, install hdparm package and run:

# hdparm -I /dev/sda | grep TRIM

  • Data Set Management TRIM supported (limit 1 block)

source: https://wiki.archlinux.org/title/Solid_state_drive#TRIM

2 Likes
5 
uwe@HAL ~]$ lsblk --discard
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
├─sda1        0      512B       2G         0
├─sda2        0      512B       2G         0
└─sda3        0      512B       2G         0
sdb           0        4K       2G         0
└─sdb1        0        4K       2G         0

sda is the SSD, sdb is an HDD.

So that would mean that my Samsung 850 evo does not support TRIM?

Edit: However, when I run the TRIM command manually, it seems to work.

6

That model certainly support TRIM, all that vendor preset crap doesn’t mean anything meaningful.

2 Likes
7

It does support TRIM since

DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) both have non-zero values.

2 Likes
8

thanx @pebcak , @keybreak :ok_hand:t2:

1 Like
9 
vendor preset: disabled

indeed exactly what @pebcak mentioned in the first post already…
It says only that after your install the package that ships the systemd service (util-linux) the status is disable but as you can see it is enabled; i this case as it is a timer it will run TRIM periodically once a week (every 7 days)

Started Discard unused blocks once a week.
3 Likes
10

From one Uwe to another, you could (should?) mark @pebcak 's post as solution to this thread.

:wink:

2 Likes
11

OK, Uwe :wink:

1 Like
12

I suppose some kind of notification that fstrim has taken place would be useful. But that would depend on the notifications given by a certain DE or what you have set up with a window manager. It would be nice to see “fstrim done” or whatever without checking logs etc.

4 Likes
13

status will tell … and possible to notify about that with a hook …
2022-07-03_00-05

3 Likes
14

Yeah the hook to notifications would be good. I’m not sure how to do that. I know how to check in a terminal and that is OK but notification would be cool!

1 Like
15

notify-send -t 100000 'Time since last successful TRIM' "$(systemctl status fstrim.timer | grep Until:)"
2022-07-03_00-41

Now needs a scheduler only like … systemd timer to run it every hour or so…

2 Likes
16

So if I am running fstrim with systemd timer once every week, how and where would I add this?

17

If you need to assure yourself that your disks are getting trimmed, just run the following command:

journalctl -u fstrim

This will list all the times fstrim has run in the past, up to the limit of how far back you have logs available. The farther back your logs go, the more instances you will see.

Of course, if you’ve just recently enabled the fstrim.timer service, there won’t be any entries until it has run the first time (by default, it is scheduled to run on each Monday).

Here’s mine; you can see that the fstrim.service ran successfully on the last 5 Mondays:

Stagger_Lee:journalctl -u fstrim
May 30 05:00:06 ts140arch systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
May 30 05:01:11 ts140arch fstrim[236032]: /home: 266.6 GiB (286286237696 bytes) trimmed on /dev/sda2
May 30 05:01:11 ts140arch fstrim[236032]: /: 31 GiB (33280368640 bytes) trimmed on /dev/sda1
May 30 05:01:11 ts140arch systemd[1]: fstrim.service: Deactivated successfully.
May 30 05:01:11 ts140arch systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot 8310c2dc828f4ff399a5557b274fca3e --
Jun 06 05:54:39 ts140arch systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 06 05:56:07 ts140arch fstrim[136320]: /home: 257.6 GiB (276633874432 bytes) trimmed on /dev/sda2
Jun 06 05:56:07 ts140arch fstrim[136320]: /: 31.3 GiB (33593942016 bytes) trimmed on /dev/sda1
Jun 06 05:56:07 ts140arch systemd[1]: fstrim.service: Deactivated successfully.
Jun 06 05:56:07 ts140arch systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot 58e277ecf1e84bddb927825a8537d69c --
Jun 13 06:07:04 ts140arch systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 13 06:08:31 ts140arch fstrim[142110]: /home: 258.2 GiB (277284184064 bytes) trimmed on /dev/sda2
Jun 13 06:08:31 ts140arch fstrim[142110]: /: 28.7 GiB (30848868352 bytes) trimmed on /dev/sda1
Jun 13 06:08:31 ts140arch systemd[1]: fstrim.service: Deactivated successfully.
Jun 13 06:08:31 ts140arch systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot b3d393ac1da847aaaf796a1529a5388b --
Jun 20 04:41:49 ts140arch systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 20 04:43:09 ts140arch fstrim[29947]: /home: 262.3 GiB (281591779328 bytes) trimmed on /dev/sda2
Jun 20 04:43:09 ts140arch fstrim[29947]: /: 27 GiB (28987314176 bytes) trimmed on /dev/sda1
Jun 20 04:43:09 ts140arch systemd[1]: fstrim.service: Deactivated successfully.
Jun 20 04:43:09 ts140arch systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot e2bdd9d7e16d4ddda90c37ba77555afc --
Jun 27 05:55:15 ts140arch systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 27 05:56:34 ts140arch fstrim[268349]: /home: 262.9 GiB (282256658432 bytes) trimmed on /dev/sda2
Jun 27 05:56:34 ts140arch fstrim[268349]: /: 25.6 GiB (27532525568 bytes) trimmed on /dev/sda1
Jun 27 05:56:34 ts140arch systemd[1]: fstrim.service: Deactivated successfully.
Jun 27 05:56:34 ts140arch systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
Stagger_Lee:
2 Likes
18

from the wiki: https://wiki.archlinux.org/title/Solid_state_drive#Periodic_TRIM

It’s a normal systemctl start/enable. Same as like Bluetooth for instance, as noted by @Stagger_Lee

If you’ve installed EOS recently, it should be installed and running already for you.

19

@fbodymechanic @Stagger_Lee yeah I have enabled the service but I had disabled my logging in journalctl for some reason I forget! My bad! Any clues on how to re-enable this?

1 Like
20

Do the opposite of what you did when you disabled logging :grin:.

2 Likes