Re: [PATCH] dm dust: use target-relative sectors in badblock messages

On Wed, Jul 22, 2026 at 5:14=E2=80=AFPM Benjamin Marzinski <bmarzins@redhat=
.com> wrote:
>
> On Tue, Jun 09, 2026 at 12:23:45AM +0000, Samuel Moelius wrote:
> > dm-dust stores bad blocks in target-relative sectors, but some messages
> > report or compare values in a different coordinate space. A table with =
a
> > non-zero target offset can therefore describe one sector while reportin=
g
> > another.
> >
> > This makes diagnostics misleading and can make scripted validation look
> > at the wrong logical block.
> >
> > Keep the badblock control path in target-relative coordinates when
> > reporting and matching stored bad blocks.
> >
> > Assisted-by: Codex:gpt-5.5-cyber-preview
> > Signed-off-by: Samuel Moelius <[email protected]>
>
> I agree that the block number is misleading to the point of being wrong.
> However I don't think that dm-dust is inconsistent. dust_message()
> checks if the bad block fits in the underlying device size. It doesn't
> check if it fits in the target size. When dust_map() is called, it
> checks for the block relative to the underlying device. So it
> consitently treats the block number as referring to a block on the
> underlying device, not referring to a block relative to the start of the
> dm-dust target. This is weird. It means that dm-dust allows you to mark
> bad blocks that aren't actually part of the dm-dust device, or mark bad
> blocks that aren't aligned with the dm-dust target. That seems wrong,
> and the code setting up max_block_sectors sure makes it look like the
> blocks are supposed to be relative to the target.  The question is, "Do
> existing dm-dust users expect this current behavior?"
> Documentation/admin-guide/device-mapper/dm-dust.rst doesn't mention what
> a bad block is relative to.
>
> Overall, I think that dm-dust is not a heavily used target, and quite
> possibly you are the first person to try using it will a non-zero offset
> on the underlying device, so I think it's probably o.k. to change the
> behavior here to something sensible. But the commit message should be
> clearer that it is changing what a badblock refers to (from a block on
> the underlying device to a block relative to the start of the dm-dust
> target).
>
> Also if you wouldn't mind removing the sector_div() line from
> __dust_map_write(), that would also be a welcome change. thisblock
> already points to the block, and dividing it by sect_per_block again
> just makes __dust_map_write() report the wrong block got removed from
> the badblocklist.

Sorry for the delay. I just sent an updated patch.