I am impressed at how much I read wrong... On Thu, Sep 24, 2020 at 1:00 PM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > On Thu, Sep 24 2020 at 12:45pm -0400, > John Dorminy <jdorminy@xxxxxxxxxx> wrote: > > > I don't understand how this works... > > > > Can chunk_size_bytes be 0? If not, how is discard_granularity being set to 0? > > Yeah, I had same question.. see the reply I just sent in this thread: > https://www.redhat.com/archives/dm-devel/2020-September/msg00568.html > > > I think also limits is local to the ti in question here, initialized > > by blk_set_stacking_limits() via dm-table.c, and therefore has only > > default values and not anything to do with the underlying queue. So > > setting discard_granularity=max(discard_granularity, chunk_size_bytes) > > doesn't seem like it should be working, unless I'm not understanding > > what it's there for... > > You're reading the dm-table.c limits stacking wrong. Of course DM stack > up the underlying device(s) limits ;) Yep, I failed to read iterate_devices... > > > > > And shouldn't melding in the target's desired io_hints into the > > existing queue limits be happening in blk_stack_limits() instead? > > (Also, it does lcm_not_zero() for stacking granularity, instead of > > max()...) > > > > DM core does do that, the .io_hints hook in the DM target is reserved > for when the target has additional constraints that blk_stack_limits() > didn't/couldn't factor in. Yes, I had erroneously thought the limit-stacking was after getting the targets' individual limits, not before. > > And blk_stack_limts() does use max() for discard_granularity. ... I'm just terrible at reading this morning. Thanks for pointing out all the things I misread! > > Mike > > > > > On Thu, Sep 24, 2020 at 12:29 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > > > This patch fixes a warning WARN_ON_ONCE(!q->limits.discard_granularity). > > > The reason is that the function raid_io_hints overwrote > > > limits->discard_granularity with zero. We need to properly stack the > > > limits instead of overwriting them. > > > > > > Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > --- > > > drivers/md/dm-raid.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > Index: linux-2.6/drivers/md/dm-raid.c > > > =================================================================== > > > --- linux-2.6.orig/drivers/md/dm-raid.c 2020-09-24 18:16:45.000000000 +0200 > > > +++ linux-2.6/drivers/md/dm-raid.c 2020-09-24 18:16:45.000000000 +0200 > > > @@ -3734,8 +3734,8 @@ static void raid_io_hints(struct dm_targ > > > * RAID0/4/5/6 don't and process large discard bios properly. > > > */ > > > if (rs_is_raid1(rs) || rs_is_raid10(rs)) { > > > - limits->discard_granularity = chunk_size_bytes; > > > - limits->max_discard_sectors = rs->md.chunk_sectors; > > > + limits->discard_granularity = max(limits->discard_granularity, chunk_size_bytes); > > > + limits->max_discard_sectors = min_not_zero(limits->max_discard_sectors, (unsigned)rs->md.chunk_sectors); > > > } > > > } > > > > > > > > > -- > > > dm-devel mailing list > > > dm-devel@xxxxxxxxxx > > > https://www.redhat.com/mailman/listinfo/dm-devel > > > > > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
