On Mon, Jun 8, 2026 at 8:07 PM Zdenek Kabelac <[email protected]> wrote: > > Dne 04. 06. 26 v 7:00 Lakshmi Narasimhan Sundararajan napsal(a): > > Hi LVM Team! A very good day to you. > > > > I have a question about the chunk size configuration supported on a > > thin pool and its relation to the exported discard_granularity on the > > many thin volumes from that pool. > > > > Per the docs, chunk sizes range from 64K to 2M and must be a multiple of > > 64K. > > So I assume , any integral units of 64K, for example, 192K (which is > > three times 64K, is also supported, even though it's not a power of > > 2). > > > > Now, I need confirmation on the correct behavior: I've observed that > > thin volumes from a thin pool use the chunk size as the discard > > granularity. To my understanding, the block layer code heavily assumes > > that the discard granularity is a power of 2. > > > > In this case, this is not honoured, and I do not fully understand the > > reason for or the impact of this behavior. Can you please help me > > understand what this setting means? > > Hi > > You need to see a difference between released space in thin-pool itself, > and sending TRIM request to underlying storage used for holding data chunks. > > Those are 2 'different' operations. > > Also typically TRIM is block based aka 4K - so the kernel can send TRIM to > individual blocks - and then it depends how the storage itself works with this > - it may need whole internal stripe - i.e. 128K or 256K to be trimmed to have > some real usefulness. > > As you can already see there are several variables which needs to be meet > together to make TRIM full passing down through whole stack to the core drive > logic and releasing 'area' within storage.
Hi Zdenek, Thank you for your response. Either I have not followed your response, or my question did not convey well. Assume a thin pool (pwx2) exists with a chunk size of 384K. Any thin volume created from that thin pool is exported as shown below. ``` root@ip-10-13-163-134:~# ls /dev/pwx2/200599089991732291 /dev/pwx2/200599089991732291 root@ip-10-13-163-134:~# lsblk -D /dev/pwx2/200599089991732291 NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO pwx2-200599089991732291 0 384K 384M 0 root@ip-10-13-163-134:~# readlink /dev/pwx2/200599089991732291 ../dm-22 root@ip-10-13-163-134:~# cat /sys/block/dm-22/queue/discard_granularity 393216 ``` Now when blkdiscard (TRIM/UNMAP variants) is used, all of it comes directly from the application (it could work on a raw disk - thin volume in this case) or a mounted fs over this block device. They issue blkdiscard or the ioctl(TRIM/UNMAP etc equivalent). Now blkdiscard targets an end user mapped/direct extent on the thin volume. The block device property exported cannot be a power of 2. This is a bug where the thin pool exports a non-power-of-2 value for discard granularity. And this would impact all operations from the app/fs. There is no mention of thin_trim in my email, but even that is impacted, as it would internally issue blkdiscard. And the behavior is undefined in this case! I cannot fathom anything other than a BUG in the thin pool stack and there is no workaround too. Please correct me if I am mistaken. > > > a) thin pools can safely support any integral multiple of 64K chunk size > > b) thin volumes always export chunk size as discard granularity > > c) thin volumes exporting a non power of 2 discard granularity implies what? > > d) what else is impacted here outside discard - and its behavior in this > > case. > > Regular IO activity is fine, as discard granularity do not impact it. > > e) anything else surrounding this context that is relevant to support > > this configuration. > > > > As always, thank you so much for your inputs. > > You are possibly overestimating the need of 'trim' - modern drives usually do > not need it - so you may only need this - when thin-pool itself runs on top of > another 'provisioned' space - where the TRIM might have some sensitivity. > > There is 'thin_trim' currently only 'offline' - which is capable for inactive > thin-pool to run through and send large 'trims' - essentially equivalence of > 'fstrim' logic - and there is some work being done to make this tool online as > need this for proper THIN+VDO integration. > > On fast modern nvme you might get possibly better performance with disabled > trim pass-through... > > Regards > > Zdenek >
