> For now, it's best to avoid using non-power-of-2 data block sizes for > thin-pools.
That suggestion is good for new deployments. But we can't do much now, given the thin pools are already constructed and in the wild. Thank you for confirming, there is no impact to the RW workflow. I hope this incorrect bit logic does not spill over to erase extents outside the given range, could you confirm on this again. Thank you again for your response, Best regards. On Tue, Jun 9, 2026 at 5:01 PM Ming Hung Tsai <[email protected]> wrote: > > 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 > > >
