2

I have two SSD disks on my system and three filesystems:

$ lsblk | grep -v '^loop'
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 465.8G  0 disk /home
sdb      8:16   0 238.5G  0 disk 
├─sdb1   8:17   0   512M  0 part /boot/efi
└─sdb2   8:18   0   238G  0 part /var/snap/firefox/common/host-hunspell
                                 /

and their utilization is like this:

$ df -BM / /home /boot/efi
Filesystem     1M-blocks    Used Available Use% Mounted on
/dev/sdb2        238777M  34465M   192112M  16% /
/dev/sda         468357M 203036M   241459M  46% /home
/dev/sdb1           511M      7M      505M   2% /boot/efi

The fstrim service runs once a week, but reports some "unnatural" values:

$ journalctl | grep   "fstrim.*/home" 
Oct 23 12:42:02 x fstrim[23187]: /home: 249.6 GiB (267956338688 bytes) trimmed on /dev/sda
Oct 30 19:19:38 x fstrim[22436]: /home: 248.9 GiB (267243692032 bytes) trimmed on /dev/sda
Nov 06 13:35:55 x fstrim[31818]: /home: 243.7 GiB (261722529792 bytes) trimmed on /dev/sda
Nov 13 11:53:32 x fstrim[11380]: /home: 242.9 GiB (260790439936 bytes) trimmed on /dev/sda
Nov 20 11:36:39 x fstrim[8200]: /home: 257.8 GiB (276775620608 bytes) trimmed on /dev/sda

$ journalctl | grep "fstrim.*/:" Oct 23 12:42:02 x fstrim[23187]: /: 197.1 GiB (211671953408 bytes) trimmed on /dev/sdb2 Oct 30 19:19:38 x fstrim[22436]: /: 197.5 GiB (212089090048 bytes) trimmed on /dev/sdb2 Nov 06 13:35:55 x fstrim[31818]: /: 197.5 GiB (212091011072 bytes) trimmed on /dev/sdb2 Nov 13 11:53:32 x fstrim[11380]: /: 198.9 GiB (213588897792 bytes) trimmed on /dev/sdb2 Nov 20 11:36:39 x fstrim[8200]: /: 199.1 GiB (213827371008 bytes) trimmed on /dev/sdb2

$ journalctl | grep "fstrim.*/efi:" Oct 23 12:42:02 x fstrim[23187]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/sdb1 Oct 30 19:19:38 x fstrim[22436]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/sdb1 Nov 06 13:35:55 x fstrim[31818]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/sdb1 Nov 13 11:53:32 x fstrim[11380]: /boot/efi: 504.9 MiB (529424384 bytes) trimmed on /dev/sdb1 Nov 20 11:36:39 x fstrim[8200]: /boot/efi: 504.9 MiB (529424384 bytes) trimmed on /dev/sdb1

My weekly usage is not uniform. For example, I have done a 23.04 → 23.10 upgrade on November 8th. Taking into consideration my usage and disk utilization, the numbers reported by fstrim do not make sense.

Can somebody help me interpret these numbers? Can somebody make similar checks on their system and see if it is also the case on that systems too? I thought that the numbers reported are supposed to be the number of block or bytes recovered after the trim operation, but it looks like they are the number of free block or bytes as known by the OS. How can I see the actual number of blocks recovered?


Note that this question may be related to How to know if my NVMe SSD needs TRIM

FedKad
  • 10,515
  • How often do you reboot your machine? – sotirov Nov 21 '23 at 17:22
  • It is a notebook computer. I never go to standby, sleep or whatever. I always shut it down (power off) at least once per day, sometimes I reboot it several times a day (due to software update, etc.). – FedKad Nov 21 '23 at 17:27
  • This may be helpful to you: https://askubuntu.com/q/729279/1157209 – sotirov Nov 21 '23 at 17:30
  • Thanks @sotirov . Although an old question, the answer seems valid. What about my very last question above? – FedKad Nov 21 '23 at 17:35
  • I think that's how TRIM works. These are my logs https://i.stack.imgur.com/5fDUI.png I am not really into restarting, and it can be seen from the image :) It's normal for me to have several weeks uptime on my laptop. – sotirov Nov 21 '23 at 17:42
  • 1
    From this we can conclude that: (1) fstrim sends all the empty (as known to the OS) blocks to SSD for recovery. This is true after the first invocation after OS boot. Subsequent runs of fstrim will only send the newly deleted blocks. However this information is lost during shutdown, so after reboot fstrim will send all deleted blocks again to SSD. (2) There's no way to know the actual number of blocks recovered by the SSD, since this information is not communicated back (?) to the OS by the SSD. – FedKad Nov 21 '23 at 18:12
  • 1
    I got to the same conclusion as you. But my TRIM knowledge is very limited... I learned most of it in the last 5 days :) – sotirov Nov 21 '23 at 18:20

1 Answers1

0

From the discussion with @sotirov on the comments above, I can conclude the following:

  1. fstrim sends all the empty (as known to the OS) blocks to SSD for recovery. This is so during its first invocation after OS boot. Subsequent runs of fstrim will only send the newly deleted blocks. However, this information is lost during OS shutdown, so after reboot fstrim will send all deleted blocks again to SSD.

  2. There's no way to know the actual number of blocks recovered by the SSD, since this information is not communicated back to the OS by the SSD.

Please comment or correct my answer.

FedKad
  • 10,515