From: antlists <antlists@youngman.org.uk>
To: Coly Li <colyli@suse.de>,
axboe@kernel.dk, dan.j.williams@intel.com,
vishal.l.verma@intel.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges
Date: Sat, 19 Dec 2020 20:02:11 +0000 [thread overview]
Message-ID: <3f4bf4c4-1f1f-b1a6-5d91-2dbe02f61e67@youngman.org.uk> (raw)
In-Reply-To: <20201203171535.67715-1-colyli@suse.de>
On 03/12/2020 17:15, Coly Li wrote:
> This patch is an initial effort to improve badblocks_set() for setting
> bad blocks range when it covers multiple already set bad ranges in the
> bad blocks table, and to do it as fast as possible.
Is this your patch, or submitted as part of the bug report?
"Heavily based on MD badblocks code from Neil Brown"
How much has this code got to do with the mdraid subsystem? Because
badblocks in mdraid has an appalling reputation, with many people
wanting to just rip it out.
If this code is separate from the mdraid implementation, any chance you
can work with it, and fix that at the same time? Or make it redundant! I
don't quite see why mdraid should need a badblocks list given modern
disk drives.
And it's on my to-do list (if I can find the time!!!) to integrate
dm-integrity into mdraid, at which point md badblocks should be irrelevant.
Hope I'm not being a shower of cold water, and if you want to fix all
this, good on you, but to the extent that this is relevant to
linux-raid, I think a lot of people will be asking "What's the point?"
Cheers,
Wol
next prev parent reply other threads:[~2020-12-19 20:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 17:15 [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges Coly Li
2020-12-18 3:25 ` Dan Williams
2020-12-20 9:50 ` Coly Li
2020-12-19 20:02 ` antlists [this message]
2020-12-20 9:46 ` Coly Li
2020-12-22 11:12 ` antlists
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=3f4bf4c4-1f1f-b1a6-5d91-2dbe02f61e67@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=axboe@kernel.dk \
--cc=colyli@suse.de \
--cc=dan.j.williams@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-raid@vger.kernel.org \
--cc=vishal.l.verma@intel.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).