From: Mike Snitzer <snitzer@redhat.com>
To: Jes.Sorensen@redhat.com
Cc: Neil Brown <neilb@suse.de>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: [PATCH 0/1] RFC: Unreliable discard performance can cripple RAID1
Date: Tue, 7 Jul 2015 00:42:48 -0400 [thread overview]
Message-ID: <CAMM=eLcd18_Vkx0O0VsmsJCbcs52Dj1hprA6u8_1CDkFQePGKQ@mail.gmail.com> (raw)
In-Reply-To: <1435105573-1373-1-git-send-email-Jes.Sorensen@redhat.com>
On Tue, Jun 23, 2015 at 8:26 PM, <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> Neil,
>
> I have been hitting issues with discard being ridiculously slow on
> arrays with certain typs of SSDs that seem to serialize discard
> processing.
>
> This is particularly bad as I have seen systems where the IMSM BIOS
> defaults to 4KB chunk size, combined with these badly performing
> drives, it could bump the mkfs on an array from seconds to over 40
> minutes. Most users will stick to the defaults and then hit the
> problem during install without understanding why it goes wrong :(
>
> The problem is that there is no way to benchmark our way to this or
> somehow test if a drive performs discard at reasonable speed. I
> suggest we take an approach similar to that of RAID456 and default to
> disabling discard, except for the case where the user knows the drives
> are safe.
>
> Thoughts?
>
> Cheers,
> Jes
>
>
> Jes Sorensen (1):
> raid0: Disable discard per default due to performance uncertainty
>
> drivers/md/raid0.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
As we've discussed in private (but for the benefit of others):
MD raid0 should do what dm-stripe does. Which is calculate the full
extent to discard for each member in the raid0.
This avoids issuing lots of small discards and hoping the block layer
merges them back up.
See this DM commit for reference:
http://git.kernel.org/linus/7b76ec11fec40203836b488496d2df082d5b2022
prev parent reply other threads:[~2015-07-07 4:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 0:26 [PATCH 0/1] RFC: Unreliable discard performance can cripple RAID1 Jes.Sorensen
2015-06-24 0:26 ` [PATCH 1/1] raid0: Disable discard per default due to performance uncertainty Jes.Sorensen
2015-06-24 5:00 ` [PATCH 0/1] RFC: Unreliable discard performance can cripple RAID1 Roman Mamedov
2015-06-24 11:04 ` Jes Sorensen
2015-06-25 1:03 ` Martin K. Petersen
2015-06-24 7:55 ` NeilBrown
2015-06-24 11:02 ` Jes Sorensen
2015-06-25 1:05 ` Martin K. Petersen
2015-07-07 4:42 ` Mike Snitzer [this message]
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='CAMM=eLcd18_Vkx0O0VsmsJCbcs52Dj1hprA6u8_1CDkFQePGKQ@mail.gmail.com' \
--to=snitzer@redhat.com \
--cc=Jes.Sorensen@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=neilb@suse.de \
/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).