Linux-Raid Archives on lore.kernel.org
 help / color / Atom feed
* RE: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
@ 2021-03-11  3:55 Adrian Huang12
  0 siblings, 0 replies; 10+ messages in thread
From: Adrian Huang12 @ 2021-03-11  3:55 UTC (permalink / raw)
  To: Xiao Ni, songliubraving
  Cc: linux-raid, matthew.ruffell, colyli, guoqing.jiang, ncroxon, hch

> -----Original Message-----
> From: Xiao Ni <xni@redhat.com>
> Sent: Thursday, February 4, 2021 1:57 PM
> To: songliubraving@fb.com
> Cc: linux-raid@vger.kernel.org; matthew.ruffell@canonical.com;
> colyli@suse.de; guoqing.jiang@cloud.ionos.com; ncroxon@redhat.com;
> hch@infradead.org
> Subject: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
> 
> Xiao Ni (5):
>   md: add md_submit_discard_bio() for submitting discard bio
>   md/raid10: extend r10bio devs to raid disks
>   md/raid10: pull the code that wait for blocked dev into one function
>   md/raid10: improve raid10 discard request
>   md/raid10: improve discard request for far layout

Hi Xiao Ni,

Thanks for this series. I also reproduced this issue when creating a RAID10 disk via
Intel VROC.

The xfs formatting process was not finished on 5.4.0-66 and 5.12.0-rc2 (waiting
for one hour), and there were lots of IO timeouts from dmesg. 

With this series (on top of 5.12.0-rc2), the xfs formatting process only took
1 second. And, I did not see any IO timeouts from dmesg.

The test detail [0] is shown as follows. 

So, feel free to add my tested-by. 

[0] https://gist.githubusercontent.com/AdrianHuang/56daafe1b4dbd8b5744d02c5a473e5cd/raw/82f33862698be2567af48b7662f08ccd8e8d27fd/raid10-issue-test-detail.log

-- Adrian

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-20  8:12   ` Xiao Ni
@ 2021-02-24  8:41     ` Song Liu
  0 siblings, 0 replies; 10+ messages in thread
From: Song Liu @ 2021-02-24  8:41 UTC (permalink / raw)
  To: Xiao Ni
  Cc: Matthew Ruffell, Song Liu, linux-raid, Coly Li, Guoqing Jiang,
	Nigel Croxon

On Sat, Feb 20, 2021 at 12:21 AM Xiao Ni <xni@redhat.com> wrote:
>
> Hi Matthew
>
> Thanks very much for those test. And as you said, it's better to wait
> more test results.
> By the way, do you know the date of 5.13 merge window?

5.13 merge window will be April (about 2 months from now).

I applied the set to md-next.

Thanks,
Song

>
> Regards
> Xiao
>
> On 02/15/2021 12:05 PM, Matthew Ruffell wrote:
> > Hi Xiao,
> >
> > Thanks for posting the patchset. I have been testing them over the past week,
> > and they are looking good.
> >
> > I backported [0] the patchset to the Ubuntu 4.15, 5.4 and 5.8 kernels, and I have
> > been testing them on public clouds.
> >
> > [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/comments/13
> >
> > For performance, formatting a Raid10 array on NVMe disks drops from 8.5 minutes
> > to about 6 seconds [1], on AWS i3.8xlarge with 4x 1.7TB disks, due to the
> > speedup in block discard.
> >
> > [1] https://paste.ubuntu.com/p/NNGqP3xdsc/
> >
> > I have also tested the data corruption reproducer from my original problem
> > report [2], and I have found that throughout each of the steps of formatting the
> > array, doing a consistency check, writing data, doing a consistency check,
> > issuing a fstrim, doing a consistency check, the /sys/block/md0/md/mismatch_cnt
> > was always 0, and all deep fsck checks came back clean for individual disks [3].
> >
> > [2] https://www.spinics.net/lists/kernel/msg3765302.html
> > [3] https://paste.ubuntu.com/p/5DK57TzdFH/
> >
> > So I think your patches do solve the data corruption problem. Great job.
> >
> > To try and get some more eyes on the patches, I have provided my test kernels to
> > 5 other users who are hitting the Raid10 block discard performance problem, and
> > I have asked them to test on spare test servers, and to provide feedback on
> > performance and data safety.
> >
> > I will let you know their feedback as it comes in.
> >
> > As for getting this merged, I actually agree with Song, the 5.12 merge window
> > is happening right now, and it is a bit too soon for large changes like this.
> > I think we should wait for the 5.13 merge window. That way we can do some more
> > testing, get feedback from some users, and make sure we don't cause any more
> > data corruption regressions.
> >
> > I will write back soon with some user feedback and more test results.
> >
> > Thanks,
> > Matthew
> >
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-15  4:05 ` Matthew Ruffell
@ 2021-02-20  8:12   ` Xiao Ni
  2021-02-24  8:41     ` Song Liu
  0 siblings, 1 reply; 10+ messages in thread
From: Xiao Ni @ 2021-02-20  8:12 UTC (permalink / raw)
  To: Matthew Ruffell, songliubraving
  Cc: linux-raid, colyli, guoqing.jiang, ncroxon

Hi Matthew

Thanks very much for those test. And as you said, it's better to wait 
more test results.
By the way, do you know the date of 5.13 merge window?

Regards
Xiao

On 02/15/2021 12:05 PM, Matthew Ruffell wrote:
> Hi Xiao,
>
> Thanks for posting the patchset. I have been testing them over the past week,
> and they are looking good.
>
> I backported [0] the patchset to the Ubuntu 4.15, 5.4 and 5.8 kernels, and I have
> been testing them on public clouds.
>
> [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/comments/13
>
> For performance, formatting a Raid10 array on NVMe disks drops from 8.5 minutes
> to about 6 seconds [1], on AWS i3.8xlarge with 4x 1.7TB disks, due to the
> speedup in block discard.
>
> [1] https://paste.ubuntu.com/p/NNGqP3xdsc/
>
> I have also tested the data corruption reproducer from my original problem
> report [2], and I have found that throughout each of the steps of formatting the
> array, doing a consistency check, writing data, doing a consistency check,
> issuing a fstrim, doing a consistency check, the /sys/block/md0/md/mismatch_cnt
> was always 0, and all deep fsck checks came back clean for individual disks [3].
>
> [2] https://www.spinics.net/lists/kernel/msg3765302.html
> [3] https://paste.ubuntu.com/p/5DK57TzdFH/
>
> So I think your patches do solve the data corruption problem. Great job.
>
> To try and get some more eyes on the patches, I have provided my test kernels to
> 5 other users who are hitting the Raid10 block discard performance problem, and
> I have asked them to test on spare test servers, and to provide feedback on
> performance and data safety.
>
> I will let you know their feedback as it comes in.
>
> As for getting this merged, I actually agree with Song, the 5.12 merge window
> is happening right now, and it is a bit too soon for large changes like this.
> I think we should wait for the 5.13 merge window. That way we can do some more
> testing, get feedback from some users, and make sure we don't cause any more
> data corruption regressions.
>
> I will write back soon with some user feedback and more test results.
>
> Thanks,
> Matthew
>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-04  7:50 Xiao Ni
@ 2021-02-15  4:05 ` Matthew Ruffell
  2021-02-20  8:12   ` Xiao Ni
  0 siblings, 1 reply; 10+ messages in thread
From: Matthew Ruffell @ 2021-02-15  4:05 UTC (permalink / raw)
  To: Xiao Ni, songliubraving; +Cc: linux-raid, colyli, guoqing.jiang, ncroxon

Hi Xiao,

Thanks for posting the patchset. I have been testing them over the past week,
and they are looking good.

I backported [0] the patchset to the Ubuntu 4.15, 5.4 and 5.8 kernels, and I have
been testing them on public clouds.

[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/comments/13

For performance, formatting a Raid10 array on NVMe disks drops from 8.5 minutes 
to about 6 seconds [1], on AWS i3.8xlarge with 4x 1.7TB disks, due to the 
speedup in block discard.

[1] https://paste.ubuntu.com/p/NNGqP3xdsc/

I have also tested the data corruption reproducer from my original problem 
report [2], and I have found that throughout each of the steps of formatting the 
array, doing a consistency check, writing data, doing a consistency check, 
issuing a fstrim, doing a consistency check, the /sys/block/md0/md/mismatch_cnt 
was always 0, and all deep fsck checks came back clean for individual disks [3].

[2] https://www.spinics.net/lists/kernel/msg3765302.html
[3] https://paste.ubuntu.com/p/5DK57TzdFH/

So I think your patches do solve the data corruption problem. Great job.

To try and get some more eyes on the patches, I have provided my test kernels to
5 other users who are hitting the Raid10 block discard performance problem, and
I have asked them to test on spare test servers, and to provide feedback on
performance and data safety.

I will let you know their feedback as it comes in.

As for getting this merged, I actually agree with Song, the 5.12 merge window
is happening right now, and it is a bit too soon for large changes like this. 
I think we should wait for the 5.13 merge window. That way we can do some more 
testing, get feedback from some users, and make sure we don't cause any more 
data corruption regressions.

I will write back soon with some user feedback and more test results.

Thanks,
Matthew

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-04  8:39     ` Xiao Ni
@ 2021-02-04 17:29       ` Song Liu
  0 siblings, 0 replies; 10+ messages in thread
From: Song Liu @ 2021-02-04 17:29 UTC (permalink / raw)
  To: Xiao Ni
  Cc: Song Liu, linux-raid, Matthew Ruffell, Coly Li, Guoqing Jiang,
	Nigel Croxon, hch

On Thu, Feb 4, 2021 at 12:39 AM Xiao Ni <xni@redhat.com> wrote:
>
>
>
> On 02/04/2021 04:12 PM, Song Liu wrote:
> > On Wed, Feb 3, 2021 at 11:42 PM Xiao Ni <xni@redhat.com> wrote:
> >> Hi Song
> >>
> >> Please ignore the v2 version. There is a place that needs to be fix.
> >> I'll re-send
> >> v2 version again.
> > What did you change in the new v2? Removing "extern" in the header?
> > For small changes like this, I can just update it while applying the patches.
> > If we do need resend (for bigger changes), it's better to call it v3.
>
> Yes, it only removes "extern" in patch1.
> >
> > I was testing the first v2 in the past hour or so, it looks good in the test.
> > I will take a closer look tomorrow. On the other hand, we are getting close
> > to the 5.12 merge window, so it is a little too late for bigger
> > changes like this.
> > Therefore, I would prefer to wait until 5.13. If you need it in 5.12 for some
> > reason, please let me know.
> Is md-next a branch that is used before merging? If so, could you merge
> the patches
> to md-next if your test pass? There is a bug that needs to be fixed in
> rhel. We can
> backport the patches if you merge the patches to md-next.

Yes, I can apply them to md-next. But I rebase it from time to time, so the
hash tag will change.

Thanks,
Song

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-04  8:12   ` Song Liu
@ 2021-02-04  8:39     ` Xiao Ni
  2021-02-04 17:29       ` Song Liu
  0 siblings, 1 reply; 10+ messages in thread
From: Xiao Ni @ 2021-02-04  8:39 UTC (permalink / raw)
  To: Song Liu
  Cc: Song Liu, linux-raid, Matthew Ruffell, Coly Li, Guoqing Jiang,
	Nigel Croxon, hch



On 02/04/2021 04:12 PM, Song Liu wrote:
> On Wed, Feb 3, 2021 at 11:42 PM Xiao Ni <xni@redhat.com> wrote:
>> Hi Song
>>
>> Please ignore the v2 version. There is a place that needs to be fix.
>> I'll re-send
>> v2 version again.
> What did you change in the new v2? Removing "extern" in the header?
> For small changes like this, I can just update it while applying the patches.
> If we do need resend (for bigger changes), it's better to call it v3.

Yes, it only removes "extern" in patch1.
>
> I was testing the first v2 in the past hour or so, it looks good in the test.
> I will take a closer look tomorrow. On the other hand, we are getting close
> to the 5.12 merge window, so it is a little too late for bigger
> changes like this.
> Therefore, I would prefer to wait until 5.13. If you need it in 5.12 for some
> reason, please let me know.
Is md-next a branch that is used before merging? If so, could you merge 
the patches
to md-next if your test pass? There is a bug that needs to be fixed in 
rhel. We can
backport the patches if you merge the patches to md-next.

Regards
Xiao


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-04  7:38 ` Xiao Ni
@ 2021-02-04  8:12   ` Song Liu
  2021-02-04  8:39     ` Xiao Ni
  0 siblings, 1 reply; 10+ messages in thread
From: Song Liu @ 2021-02-04  8:12 UTC (permalink / raw)
  To: Xiao Ni
  Cc: Song Liu, linux-raid, Matthew Ruffell, Coly Li, Guoqing Jiang,
	Nigel Croxon, hch

On Wed, Feb 3, 2021 at 11:42 PM Xiao Ni <xni@redhat.com> wrote:
>
> Hi Song
>
> Please ignore the v2 version. There is a place that needs to be fix.
> I'll re-send
> v2 version again.

What did you change in the new v2? Removing "extern" in the header?
For small changes like this, I can just update it while applying the patches.
If we do need resend (for bigger changes), it's better to call it v3.

I was testing the first v2 in the past hour or so, it looks good in the test.
I will take a closer look tomorrow. On the other hand, we are getting close
to the 5.12 merge window, so it is a little too late for bigger
changes like this.
Therefore, I would prefer to wait until 5.13. If you need it in 5.12 for some
reason, please let me know.

Thanks,
Song

>
> Regards
> Xiao
>
> On 02/04/2021 01:57 PM, Xiao Ni wrote:
> > Hi all
> >
> > Now mkfs on raid10 which is combined with ssd/nvme disks takes a long time.
> > This patch set tries to resolve this problem.
> >
> > This patch set had been reverted because of a data corruption problem. This
> > version fix this problem. The root cause which causes the data corruption is
> > the wrong calculation of start address of near copies disks.
> >
> > Now we use a similar way with raid0 to handle discard request for raid10.
> > Because the discard region is very big, we can calculate the start/end
> > address for each disk. Then we can submit the discard request to each disk.
> > But for raid10, it has copies. For near layout, if the discard request
> > doesn't align with chunk size, we calculate a start_disk_offset. Now we only
> > use start_disk_offset for the first disk, but it should be used for the
> > near copies disks too.
> >
> > [  789.709501] discard bio start : 70968, size : 191176
> > [  789.709507] first stripe index 69, start disk index 0, start disk offset 70968
> > [  789.709509] last stripe index 256, end disk index 0, end disk offset 262144
> > [  789.709511] disk 0, dev start : 70968, dev end : 262144
> > [  789.709515] disk 1, dev start : 70656, dev end : 262144
> >
> > For example, in this test case, it has 2 near copies. The start_disk_offset
> > for the first disk is 70968. It should use the same offset address for second disk.
> > But it uses the start address of this chunk. It discard more region. This version
> > simply spilt the un-aligned part with strip size.
> >
> > And it fixes another problem. The calculation of stripe_size is wrong in reverted version.
> >
> > V2: Fix problems pointed by Christoph Hellwig.
> >
> > Xiao Ni (5):
> >    md: add md_submit_discard_bio() for submitting discard bio
> >    md/raid10: extend r10bio devs to raid disks
> >    md/raid10: pull the code that wait for blocked dev into one function
> >    md/raid10: improve raid10 discard request
> >    md/raid10: improve discard request for far layout
> >
> >   drivers/md/md.c     |  20 +++
> >   drivers/md/md.h     |   2 +
> >   drivers/md/raid0.c  |  14 +-
> >   drivers/md/raid10.c | 434 +++++++++++++++++++++++++++++++++++++++++++++-------
> >   drivers/md/raid10.h |   1 +
> >   5 files changed, 402 insertions(+), 69 deletions(-)
> >
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
@ 2021-02-04  7:50 Xiao Ni
  2021-02-15  4:05 ` Matthew Ruffell
  0 siblings, 1 reply; 10+ messages in thread
From: Xiao Ni @ 2021-02-04  7:50 UTC (permalink / raw)
  To: songliubraving
  Cc: linux-raid, matthew.ruffell, colyli, guoqing.jiang, ncroxon

Hi all

Now mkfs on raid10 which is combined with ssd/nvme disks takes a long time.
This patch set tries to resolve this problem.

This patch set had been reverted because of a data corruption problem. This
version fix this problem. The root cause which causes the data corruption is
the wrong calculation of start address of near copies disks.

Now we use a similar way with raid0 to handle discard request for raid10.
Because the discard region is very big, we can calculate the start/end
address for each disk. Then we can submit the discard request to each disk.
But for raid10, it has copies. For near layout, if the discard request
doesn't align with chunk size, we calculate a start_disk_offset. Now we only
use start_disk_offset for the first disk, but it should be used for the
near copies disks too.

[  789.709501] discard bio start : 70968, size : 191176
[  789.709507] first stripe index 69, start disk index 0, start disk offset 70968
[  789.709509] last stripe index 256, end disk index 0, end disk offset 262144
[  789.709511] disk 0, dev start : 70968, dev end : 262144
[  789.709515] disk 1, dev start : 70656, dev end : 262144

For example, in this test case, it has 2 near copies. The start_disk_offset
for the first disk is 70968. It should use the same offset address for second disk.
But it uses the start address of this chunk. It discard more region. This version
simply spilt the un-aligned part with strip size.

And it fixes another problem. The calculation of stripe_size is wrong in reverted version.

V2: Fix problems pointed by Christoph Hellwig.

Xiao Ni (5):
  md: add md_submit_discard_bio() for submitting discard bio
  md/raid10: extend r10bio devs to raid disks
  md/raid10: pull the code that wait for blocked dev into one function
  md/raid10: improve raid10 discard request
  md/raid10: improve discard request for far layout

 drivers/md/md.c     |  20 +++
 drivers/md/md.h     |   2 +
 drivers/md/raid0.c  |  14 +-
 drivers/md/raid10.c | 434 +++++++++++++++++++++++++++++++++++++++++++++-------
 drivers/md/raid10.h |   1 +
 5 files changed, 402 insertions(+), 69 deletions(-)

-- 
2.7.5


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
  2021-02-04  5:57 Xiao Ni
@ 2021-02-04  7:38 ` Xiao Ni
  2021-02-04  8:12   ` Song Liu
  0 siblings, 1 reply; 10+ messages in thread
From: Xiao Ni @ 2021-02-04  7:38 UTC (permalink / raw)
  To: songliubraving
  Cc: linux-raid, matthew.ruffell, colyli, guoqing.jiang, ncroxon, hch

Hi Song

Please ignore the v2 version. There is a place that needs to be fix. 
I'll re-send
v2 version again.

Regards
Xiao

On 02/04/2021 01:57 PM, Xiao Ni wrote:
> Hi all
>
> Now mkfs on raid10 which is combined with ssd/nvme disks takes a long time.
> This patch set tries to resolve this problem.
>
> This patch set had been reverted because of a data corruption problem. This
> version fix this problem. The root cause which causes the data corruption is
> the wrong calculation of start address of near copies disks.
>
> Now we use a similar way with raid0 to handle discard request for raid10.
> Because the discard region is very big, we can calculate the start/end
> address for each disk. Then we can submit the discard request to each disk.
> But for raid10, it has copies. For near layout, if the discard request
> doesn't align with chunk size, we calculate a start_disk_offset. Now we only
> use start_disk_offset for the first disk, but it should be used for the
> near copies disks too.
>
> [  789.709501] discard bio start : 70968, size : 191176
> [  789.709507] first stripe index 69, start disk index 0, start disk offset 70968
> [  789.709509] last stripe index 256, end disk index 0, end disk offset 262144
> [  789.709511] disk 0, dev start : 70968, dev end : 262144
> [  789.709515] disk 1, dev start : 70656, dev end : 262144
>
> For example, in this test case, it has 2 near copies. The start_disk_offset
> for the first disk is 70968. It should use the same offset address for second disk.
> But it uses the start address of this chunk. It discard more region. This version
> simply spilt the un-aligned part with strip size.
>
> And it fixes another problem. The calculation of stripe_size is wrong in reverted version.
>
> V2: Fix problems pointed by Christoph Hellwig.
>
> Xiao Ni (5):
>    md: add md_submit_discard_bio() for submitting discard bio
>    md/raid10: extend r10bio devs to raid disks
>    md/raid10: pull the code that wait for blocked dev into one function
>    md/raid10: improve raid10 discard request
>    md/raid10: improve discard request for far layout
>
>   drivers/md/md.c     |  20 +++
>   drivers/md/md.h     |   2 +
>   drivers/md/raid0.c  |  14 +-
>   drivers/md/raid10.c | 434 +++++++++++++++++++++++++++++++++++++++++++++-------
>   drivers/md/raid10.h |   1 +
>   5 files changed, 402 insertions(+), 69 deletions(-)
>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
@ 2021-02-04  5:57 Xiao Ni
  2021-02-04  7:38 ` Xiao Ni
  0 siblings, 1 reply; 10+ messages in thread
From: Xiao Ni @ 2021-02-04  5:57 UTC (permalink / raw)
  To: songliubraving
  Cc: linux-raid, matthew.ruffell, colyli, guoqing.jiang, ncroxon, hch

Hi all

Now mkfs on raid10 which is combined with ssd/nvme disks takes a long time.
This patch set tries to resolve this problem.

This patch set had been reverted because of a data corruption problem. This
version fix this problem. The root cause which causes the data corruption is
the wrong calculation of start address of near copies disks.

Now we use a similar way with raid0 to handle discard request for raid10.
Because the discard region is very big, we can calculate the start/end
address for each disk. Then we can submit the discard request to each disk.
But for raid10, it has copies. For near layout, if the discard request
doesn't align with chunk size, we calculate a start_disk_offset. Now we only
use start_disk_offset for the first disk, but it should be used for the
near copies disks too.

[  789.709501] discard bio start : 70968, size : 191176
[  789.709507] first stripe index 69, start disk index 0, start disk offset 70968
[  789.709509] last stripe index 256, end disk index 0, end disk offset 262144
[  789.709511] disk 0, dev start : 70968, dev end : 262144
[  789.709515] disk 1, dev start : 70656, dev end : 262144

For example, in this test case, it has 2 near copies. The start_disk_offset
for the first disk is 70968. It should use the same offset address for second disk.
But it uses the start address of this chunk. It discard more region. This version
simply spilt the un-aligned part with strip size.

And it fixes another problem. The calculation of stripe_size is wrong in reverted version.

V2: Fix problems pointed by Christoph Hellwig.

Xiao Ni (5):
  md: add md_submit_discard_bio() for submitting discard bio
  md/raid10: extend r10bio devs to raid disks
  md/raid10: pull the code that wait for blocked dev into one function
  md/raid10: improve raid10 discard request
  md/raid10: improve discard request for far layout

 drivers/md/md.c     |  20 +++
 drivers/md/md.h     |   2 +
 drivers/md/raid0.c  |  14 +-
 drivers/md/raid10.c | 434 +++++++++++++++++++++++++++++++++++++++++++++-------
 drivers/md/raid10.h |   1 +
 5 files changed, 402 insertions(+), 69 deletions(-)

-- 
2.7.5


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-11  3:55 [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request Adrian Huang12
  -- strict thread matches above, loose matches on Subject: below --
2021-02-04  7:50 Xiao Ni
2021-02-15  4:05 ` Matthew Ruffell
2021-02-20  8:12   ` Xiao Ni
2021-02-24  8:41     ` Song Liu
2021-02-04  5:57 Xiao Ni
2021-02-04  7:38 ` Xiao Ni
2021-02-04  8:12   ` Song Liu
2021-02-04  8:39     ` Xiao Ni
2021-02-04 17:29       ` Song Liu

Linux-Raid Archives on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-raid/0 linux-raid/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-raid linux-raid/ https://lore.kernel.org/linux-raid \
		linux-raid@vger.kernel.org
	public-inbox-index linux-raid

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-raid


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git