Re: Reg thin pool chunk size and its impact on discard granularity

On Thu, Jun 4, 2026 at 1:06=E2=80=AFPM 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 wh=
at?

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
>