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.
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
