[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05249654-3088-d3e1-570d-79f58019377c@huaweicloud.com>
Date: Wed, 10 Sep 2025 16:31:47 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: John Garry <john.g.garry@...cle.com>, Zhang Yi
<yi.zhang@...weicloud.com>, linux-block@...r.kernel.org,
linux-raid@...r.kernel.org, drbd-dev@...ts.linbit.com
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, hch@....de,
martin.petersen@...cle.com, axboe@...nel.dk, yi.zhang@...wei.com,
yangerkun@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 1/2] md: init queue_limits->max_hw_wzeroes_unmap_sectors
parameter
Hi,
在 2025/09/02 20:25, John Garry 写道:
>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>> index 408c26398321..35c6498b4917 100644
>> --- a/drivers/md/raid1.c
>> +++ b/drivers/md/raid1.c
>> @@ -3211,6 +3211,7 @@ static int raid1_set_limits(struct mddev *mddev)
>> md_init_stacking_limits(&lim);
>> lim.max_write_zeroes_sectors = 0;
>> + lim.max_hw_wzeroes_unmap_sectors = 0;
>
> It would be better if we documented why we cannot support this on
> raid1/10, yet we can on raid0.
>
> I am looking through the history of why max_write_zeroes_sectors is set
> to zero. I have gone as far back as 5026d7a9b, and this tells us that
> the retry mechanism for WRITE SAME causes an issue where mirrors are
> offlined (and so we disabled the support); and this was simply copied
> for write zeroes in 3deff1a70.
Yes, we don't support it for now, and I think it is not too hard to
support write zeros, and finaly to support unmap zeros. BTW, raid5
discard is in the same suituation.
However, I feel this is not related to this set, perhaps a seperate
patch to add comments, I can accept that.
Thanks,
Kuai
Powered by blists - more mailing lists