From: Phil Turmel <philip@turmel.org>
To: Roy Sigurd Karlsbakk <roy@karlsbakk.net>,
Linux Raid <linux-raid@vger.kernel.org>
Subject: Re: Confusing output of --examine-badblocks1 message
Date: Sat, 15 Aug 2020 11:03:35 -0400 [thread overview]
Message-ID: <de6e9dd1-7447-54ab-1818-ceabf422c8a0@turmel.org> (raw)
In-Reply-To: <573421659.22903312.1597428439621.JavaMail.zimbra@karlsbakk.net>
On 8/14/20 2:07 PM, Roy Sigurd Karlsbakk wrote:
>> I just tried another approach, mdadm --remove on the spares, mdadm --examine on
>> the removed spares, no superblock. Then madm --fail for one of the drives and
>> mdadm --add for another, now spare for a few milliseconds until recovery
>> started. This runs as it should, slower than --replace, but I don't care. After
>> 12% or so, I checked with --examine-badblocks, and the same sectors are popping
>> up again. This was just a small test to see i --replace was the "bad guy" here
>> or if a full recovery would do the same. It does.
>
> For the record, I just tested mdadm --replace again on a disk in the raid. The source disk had no badblocks. The destination disk is new-ish (that is, a few years old, but hardly written to and without an md superblock). It seems the badblocks present on other drives in the raid6 are also replicated to the "new" disk. This is not really how it should be IMO.
>
> There must be a major bug in here somewhere. If there's a bad sector somewhere, well, ok, I can handle some corruption. The filesystem will probably be able to handle it as well. But if this is all blocked because of flakey "bad" sectors not really being bad, then something is bad indeed.
In my not-so-humble opinion, the bug is the existence of the BadBlocks
feature. Once a badblock is recorded for a sector, redundancy is
permanently lost at that location. There is no tool to undo this.
I strongly recommend that you remove badblock logs on all arrays before
the "feature" screws you.
Phil
next prev parent reply other threads:[~2020-08-15 22:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 12:14 Confusing output of --examine-badblocks1 message Roy Sigurd Karlsbakk
2020-08-13 14:31 ` Roy Sigurd Karlsbakk
2020-08-13 18:50 ` Roy Sigurd Karlsbakk
2020-08-14 18:07 ` Roy Sigurd Karlsbakk
2020-08-15 15:03 ` Phil Turmel [this message]
2020-08-15 17:33 ` Roy Sigurd Karlsbakk
2020-08-15 21:43 ` Phil Turmel
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=de6e9dd1-7447-54ab-1818-ceabf422c8a0@turmel.org \
--to=philip@turmel.org \
--cc=linux-raid@vger.kernel.org \
--cc=roy@karlsbakk.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.