LVS showing wrong size of data used

[Whisper40]

I encouter a problem/bug with Debian 10 and my LVM Thin just installed.
I setup my lvm with this :

umount /home
vgcreate vg_home /dev/sda2
lvcreate -l 100%FREE --thinpool pool_0_vg_home vg_home
lvcreate -V 5G --thin -n user vg_home/pool_0_vg_home
mkdir -p /home/whisper40/data/user
mkfs.ext4 /dev/vg_home/user
echo "/dev/vg_home/user /home/whisper40/data/user   ext4    defaults        0       2" >> /etc/fstab

No problem, all is working.
I add some data, ok space is growing up..

I delete the data, and.. the lvs report again the same value, the value of never decrease.
df-h report the right value 1% used, but lvs report 30% used.

If i use this command : fstrim -v /home/whisper40/data/user it updates the data value. But i don't understand what's wrong with this, it should report me all time the right value. I don't want to execute this command everytime.. that makes no sense
This is my discard mode
I already read the Discard part of this documentation : https://man7.org/linux/man-pages/man7/lvmthin.7.html

My windows machine has NVME disk
I'm running thoses commands on Debian 10 on Vmware

[Whisper40]

If i put in my fstab defaults,discard it seems to work, normal ?

[zkabelac]

Yep this is all ok/normal - you can either mount your ext4 filesystem with automatic discard - or you can mount it without discard and run 'fstrim' periodically i.e. by cron - if you wonder why is the 2nd. option better is - it's performing way better as discarding data with each removed block is quite expensive and also you may not get big enough 'blocks' for discard as clearly the minimal 'worth' discard must discard at least single think chunk. Hopefully this makes it more clear.

[Whisper40]

Ok thanks for your explanation ! Will have to think about this :)
Can you let me know if this thing is only because i have an NVME ?
Same thing with HDD ?

[zkabelac]

Triming the filesystem makes sense if the underlying devices is processing it.

So the graph extX -> thin -> thinpool -> hdd/sdd - makes obvious that whenever you use thin - and you want to release space in thin-pool for some reason - you need to discard unused space - for this 'fstrim' command your best option.

When you use 'extX -> NVMe' - trimming can release blocks on device allowing disk to prepare such block for reuse - this was helpful in past to avoid slowdown of SSDs - but nowaydays it's not so much useful.... (note - usually the size of this block is 512KiB or more.... - so discard of unaligned blocks bellow this size will not help at all....

[Whisper40]

Ok thanks for all information. In my case i have one pool and about 30 volumes in it. So i have to create a crontab to fstrim all volumes ? Or there is something that i can do on the whole pool ?

Volumes's data in my case are really changing a lot.

[zkabelac]

Thin pool itself has no idea who is user of allocated thin-pool chunks - so it always has to be driven through the filesystem.
The fstrim likely needs to be mainly used when you are running short on free space in thin-pool.

Also it's good idea to trim your fs before you take its thin snapshot.

If you remove space in your filesystem - and you continue to use your filesystem - then this space gets quickly reused anyway - and in the case the space is not discarded in thin-pool - there is no need to provision chunks again - so it's faster!

Note - filesystem is on the top of block device which is your thin volume - there is no connection between those two.
Unlike with filesystems like ZFS/btrfs where the volume management and filesystem are joined together into a complex thing.

[Whisper40]

Yesterday i had the case where I put some data, I deleted the data, I add again some data ( 50% space of the maximum possible), and the thin pool was 100% with warnings
And when i have run fstrim it goes back to 30%.

So i don't think the space is guickly reused..

[zkabelac]

Here I think you are comparing apples & oranges. If you know you will not need the space in any given filesystem - aka you know you are mostly deleting all data in FS and you are not going to fill it again - then clearly 'fstrim' IS the tool you want to use after such massive delete.

If this is your typical use-case - then you may need to schedule 'fstrim' to be run more often.

Also note - thin-pool IS not meant to be used around its boundary conditions as a part of regular workflow - condition of the full thin-pool is not equivalent case to full filesystem.

[Whisper40]

My goal is to use it on a torrent system. So users can add content, delete it few days later, so the content is regularly changing.
Actually i made a little script that is executed each 5 minutes only if the pool has above 80% of data used.

[zkabelac]

Hopefully you now understand associated logic around thus closing the issue.
It might be worth to explore dmeventd with its option monitoring which can execute user's script at 50,55,..,95,100% fullness.