Hi
I just saw your posts right now. (After posting my text "[PATCH] dm-raid: set discard_granularity non-zero if possible" yesterday)
How about iterating over all meta-devices corresponding to the raid1? Having mixed technology devices (TRIM and nonTRIM) I assume discard should be switched off? So using lcm_with_zero would be more suitable?
BR Stephan
On 24.09.20 18:56, John Dorminy wrote:
On Thu, Sep 24, 2020 at 1:24 PM John Dorminy <jdorminy@xxxxxxxxxx> wrote:
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!
Actually, though, I don't understand why it should be max instead of
lcm_not_zero(). If the raid's chunk size is 1024 sectors, say, and
you're constructing it on something that has discard_granularity 812
sectors, say, blkdev_issue_discard will be generating 1024 sector IOs
which will work poorly when passed down to the 812-sector-granularity
underlying device. While, if lcm(812,1024) were used, lcm(812,1024)
sector IOs would be compatible with both the chunk size and underlying
device's granularity, perhaps? Maybe I'm missing something, but I read
the doc and code an extra time around this time ;)
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
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 8d2b835d7a10..4c769fd93ced 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -3734,8 +3734,36 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits)
* 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;
+ /* HACK */
+ if (chunk_size_bytes==0) {
+ unsigned int i, chunk_sectors=(UINT_MAX >> SECTOR_SHIFT);
+ struct request_queue *q = NULL;
+
+ DMINFO("chunk_size is 0 for raid1 - preventing issue with TRIM");
+
+ for (i=0;i<rs->raid_disks;i++) {
+ q=bdev_get_queue(rs->dev[i].meta_dev->bdev);
+ if (chunk_sectors > q->limits.max_discard_sectors) {
+ chunk_sectors = q->limits.max_discard_sectors;
+ }
+ if (chunk_size_bytes < q->limits.discard_granularity) {
+ chunk_size_bytes = q->limits.discard_granularity;
+ }
+
+ /* lcm(x,y,...,0) = 0 */
+ if (q->limits.discard_granularity == 0) {
+ chunk_size_bytes = 0;
+ break;
+ }
+ }
+
+ limits->discard_granularity = chunk_size_bytes;
+ limits->max_discard_sectors = chunk_sectors;
+ /* end of HACK (but not of if) */
+ } else {
+ limits->discard_granularity = chunk_size_bytes;
+ limits->max_discard_sectors = rs->md.chunk_sectors;
+ }
}
}
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
