On Thu, Jun 4, 2026 at 1:06 PM Lakshmi Narasimhan Sundararajan
<[email protected]> wrote:
>
> 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?
>
> a) thin pools can safely support any integral multiple of 64K chunk size
Yes
> b) thin volumes always export chunk size as discard granularity
Yes
> c) thin volumes exporting a non power of 2 discard granularity implies what?
Because the block layer's bio_discard_limit() assumes a power-of-2
discard_granularity, a thin device with a non-power-of-2 block size
may fail to reclaim space at certain offsets. For example, given a
thin-pool with 192kb block size, discarding a single block at offset
384kb fails because round_up() misaligns the bio split point,
producing two partial-block bios that are both dropped:
blkdiscard /dev/mapper/thin -l $((192 << 10)) -o $((192 << 11))
This is an issue introduced by 9b15d109a6b2 ("block: improve discard
bio alignment in __blkdev_issue_discard()"). That commit honors
discard_granularity to avoid bio boundaries falling mid-granularity on
the device, but it uses round_up()/round_down() which require
power-of-2 arguments.
While this could be addressed in the block layer or worked around in
dm-thin, further investigation is needed.
> 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.
Right, regular IO is fine.
> e) anything else surrounding this context that is relevant to support
> this configuration.
Some filesystems also assume a power-of-2 discard_granularity. For
example, ntfs3 uses bitwise arithmetic on the value for discard
alignment, which would produce incorrect trim ranges on a thin volume
with a non-power-of-2 block size.
For now, it's best to avoid using non-power-of-2 data block sizes for
thin-pools.
> As always, thank you so much for your inputs.
> Best regards
> LN
>
