linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiao Ni <xni@redhat.com>
To: Matthew Ruffell <matthew.ruffell@canonical.com>, songliubraving@fb.com
Cc: linux-raid@vger.kernel.org, colyli@suse.de,
	guoqing.jiang@cloud.ionos.com, ncroxon@redhat.com
Subject: Re: [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request
Date: Sat, 20 Feb 2021 16:12:29 +0800	[thread overview]
Message-ID: <75ba722d-f11e-ebe5-5507-b0c380c203e9@redhat.com> (raw)
In-Reply-To: <d86c7211-787f-ee34-d2c1-cf780ecd9322@canonical.com>

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
>


  reply	other threads:[~2021-02-20  8:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  7:50 [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request Xiao Ni
2021-02-04  7:50 ` [PATCH V2 1/5] md: add md_submit_discard_bio() for submitting discard bio Xiao Ni
2021-02-04  7:50 ` [PATCH V2 2/5] md/raid10: extend r10bio devs to raid disks Xiao Ni
2021-02-04  7:50 ` [PATCH V2 3/5] md/raid10: pull the code that wait for blocked dev into one function Xiao Ni
2021-02-04  7:50 ` [PATCH V2 4/5] md/raid10: improve raid10 discard request Xiao Ni
2021-02-04  7:50 ` [PATCH V2 5/5] md/raid10: improve discard request for far layout Xiao Ni
2021-02-15  4:05 ` [PATCH V2 0/5] md/raid10: Improve handling raid10 discard request Matthew Ruffell
2021-02-20  8:12   ` Xiao Ni [this message]
2021-02-24  8:41     ` Song Liu
  -- strict thread matches above, loose matches on Subject: below --
2021-03-11  3:55 Adrian Huang12
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=75ba722d-f11e-ebe5-5507-b0c380c203e9@redhat.com \
    --to=xni@redhat.com \
    --cc=colyli@suse.de \
    --cc=guoqing.jiang@cloud.ionos.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=matthew.ruffell@canonical.com \
    --cc=ncroxon@redhat.com \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).