mjhjmtu

It is recommended to enable a TRIM cron job which run once every week.
When the fstrim command is called the filesystem will sent TRIM information to the drive to discard deleted data (I hope I get it right)

So far so good, this is described many places.

But I cannot find any information about how/where those TRIM information are "stored" in the filesystem between the fstrim commands?

And can those TRIM information be "cleared" in some way so the SSD will not get the information of all the pages/blocks that has to be discarded?

Or will the fstrim command compare the filesystem and the SSD in regards to which data is actually deleted?

I don't know if ext4 actually stores it anywhere. Other filesystems certainly don't.

ext4 avoids what it already trimmed in the current session only - while it's still mounted. Once you reboot or re-mount the filesystem, it just TRIMs empty space all over again.

So this could be an in-memory structure that isn't stored at all. I didn't dive into the very fine source code to find out.

A little test:

# truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop

Given a 1G filesystem, let's mount and trim it:

# mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed

So it first trims all... that alone is already suspicious, after all: mkfs already trimmed too (ouch), so it should know it's still empty and trimmed, right? Well, if it knows, it doesn't care:

# umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed

So after re-mount, it just trims all free space again.

When creating and deleting files, it's not pinpoint precision either:

# dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed

So, writing 10M causes a re-trim of 117M. It just doesn't mean anything.

Only the SSD itself really knows what's currently trimmed and what not, and when asked to trim an already trimmed area, it should simply do nothing. So no harm done and no need to really store this information in the filesystem.