At this moment I'd probably not recommend to use  'fstrim' on regular basis on VDO volume - as it simply (IMHO) to CPU invasive and slow operation with VDO volumes (unlike with thin volumes) - and it really depends on a use-case.

In the case that such 'freed space' is later reused again by the filesystem - the discarding operation would dramatically 'slow down' user experience.
(and currently we support only a single VDO volume per VDO pool - so such 'free space' can't be used for other VDO volumes)

So 'fstrim' with VDO should really be used only in case where the user is running out of VDO device space and he expects some 'major' freeing of the space in filesystem - which is kind of not completely obvious to guess from a used filesystem  - as from 'df' need to be derived, how the used filesystem space is matching used space in VDO volume.

But surely we can provide some VDO man page chapter giving some useful math hints about this. But it's really an 'expert user' topic.

Also such 'VDO' user experience is not actually 'VDO only' related - it's more a 'common know-how' with usage of any provisioned volumes with common linux filesystems (XFS, extX,...) - so it might forth a separate man7 page -  as we sometimes see even bad combination of using ZFS, Btrfs on top of such devices which is causing performance degradations for users.

So if 'fstrim' is not recommended what are the other correct ways to free up the vdo pool? 

I tested 'discard' mount option and that one does not work at all (still considering just a simple 'rm' operation), so I'm curious how this should be set up properly then.

Sorry about the previous comment about 'discard' mount. Must have done something wrong last time because it seems to work just fine when I tried it today:


# lvs -o lv_name,data_percent vg
  LV        Data%
  vdovolume 28.53
  vpool0    50.06

# df -h /mnt/test
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/vg-vdovolume  6.9G  2.0G  4.5G  31% /mnt/test

# mount | grep /mnt/test
/dev/mapper/vg-vdovolume on /mnt/test type ext4 (rw,relatime,seclabel,discard)

# rm -rf /mnt/test/file

# lvs -o lv_name,data_percent vg
  LV        Data%
  vdovolume 0.52
  vpool0    30.53


Anyway, if this is the recommended way of using lvm vdo (with continuous discard) it would be certainly nice to have this highlighted somewhere. Hard to say how well known this is but few lines about this in manpage sounds reasonable. Or how about a hint message when creating the vdo volume?

Nope - in fact, personally I'd never recommend to mount fs with 'discard' option enabled.
This is simply slow and inefficient.

In general users should NOT need to use discard with VDO volume - when they are overwriting SAME data space - i.e.
user writes file & removes file & writes file again - there is no need to discard in between - it will kill performance.

User MAY need to use discard if he are basically wants to really free some space in the VDO pool.

Then you SHOULD use  fstrim  -  there is just big warning - IT WILL BE SLOW! - so it will takes it's time.
There is nothing better ATM you can do.

So comment 2 is not correct -  usage of trimming on VDO device should be  much more limited compared  to
other device types - but user of course can use it, he just needs to be aware it is very CPU&disk intesive operation,
that can heavily impact performance of the system while  TRIM operation is running.

Alright, that sounds like users need to be pretty sure about the data duplicity up front. Because with each write of data that can *not* be deduplicated the pool % will just keep going up. So if the prediction is wrong and such data keep going in and out the device it could fill up the pool pretty quick. Seems a bit odd but if that's the use case...

Having that in mind it seems quite crucial to keep track of vdo pool efficiency. Is this the recommended/only way of checking it now?

# lvs -o lv_name,vdo_saving_percent vg
  LV        VDOSaving%
  vdovolume       0.12
  vpool0          0.12

# cp /mnt/test/file /mnt/test/file2

# lvs -o lv_name,vdo_saving_percent vg
  LV        VDOSaving%
  vdovolume      47.03
  vpool0         47.03

Yeah - running 'fstrim' without 'a good reason' for it - isn't very practical with VDO volume - price is relatively high.

NoteI: using overprovisioning with small VDO pool and large VDO volume and storing there content of '/dev/urandom' isn't the case  VDO is targeting to solve.  Clearly VDO is serving to user having large data duplicity - otherwise again - user is paying large amount of CPU cycle & disk bandwith to store something which can be way more efficiently stored on a linear device.

So while the starting example of this BZ is nice way to 'hit corner' cases of overfilling VDO pools quickly, the overall usage of TRIM is not needed that much (just like with modern SSD) - there is 'some help' if you use it -but it should also work without it.

NoteII: once lvm2 will deploy multiple VDO LVs per single VDO pool - usage of TRIM may relax/free space in VDO pool for 'other VDO LVs' in the same pool - but that's currently not supported.

Monitoring of VDO pools should be used as a way how to extend VDO pool 'just-in-time' where the free space is get low.

Overprovisioning is not meant to be used like an 'overfilled filesystem' - it's incomparable.  It's more about postponing adding necessary space when it's needed (i.e. adding new disk into VG). Reaching device out-of-space condition is not going to be 'user pleasant' experience, where user can easily continue to use such device - unless whole device stack together would filesystem would be heavily cooperative.

Saying this means - a user who whish to operate his dm VDO (or dm thin-pool) with nearly 'full pool' - needs to pick different technology.

FWIW, the VDO team is working on improving discard performance.  Perhaps we can update the man page when that is ready.  (Rather than recommend something that will be noticeably slow.)  OTOH, it might be useful at the moment to mention discards /and/ mention that it is currently slow.

Resolved by fix for https://bugzilla.redhat.com/show_bug.cgi?id=1855804.

Manpage now warns user about limitations when using discard operation.