From: Brad Campbell <lists2009@fnarfbargle.com>
To: Phil Turmel <philip@turmel.org>, linux-raid@vger.kernel.org
Subject: Re: Does a "check" of a RAID6 actually read all disks in a stripe?
Date: Wed, 29 Apr 2020 20:56:00 +0800 [thread overview]
Message-ID: <a1ebabac-6674-2907-55a6-41479c469232@fnarfbargle.com> (raw)
In-Reply-To: <f45df6fc-63eb-a1da-ca0c-5a3db08b454a@turmel.org>
On 28/4/20 10:41 pm, Phil Turmel wrote:
> On 4/28/20 10:00 AM, Brad Campbell wrote:
>>
>> On 28/4/20 9:47 pm, Phil Turmel wrote:
>
>>> The bad block log misfeature is turned on. Any blocks recorded in it will never be read again by MD, last I looked. This might explain what you are seeing.
>>>
test:/sys/block/md3/md# mdadm --examine-badblocks /dev/sd[ceghijklm]
Bad-blocks list is empty in /dev/sdc
Bad-blocks list is empty in /dev/sde
Bad-blocks list is empty in /dev/sdg
Bad-blocks list is empty in /dev/sdh
Bad-blocks list is empty in /dev/sdi
Bad-blocks list is empty in /dev/sdj
Bad-blocks list is empty in /dev/sdk
Bad-blocks list is empty in /dev/sdl
Bad-blocks list is empty in /dev/sdm
>> While I see where you are going, the fact it corrected the bad sector by re-writing it during the re-build would intimate that isn't/wasn't the case.
>
> Ah, yes. Any chance you have set the sysfs sector limits on a check and haven't reset them?
>
> Phil
>
No. Each run was triggered by an :
echo check > /sys/block/md3/md/sync_action
No other interaction with sysfs.
I have a few drives in another machine I can abuse, so I have some time put aside on the weekend to set up a couple of small test arrays. When I last tried (admittedly years ago now) it was easy enough to "create" bad blocks with hdparm.
I think Piergiorgio was on the money with something not reading one of the parity blocks, but I've read the code several times and can't see obviously how that might be the case. I suppose examining a check with blktrace would highlight it if that were the case. I might try that first.
On the topic of the bbl. Is there any way to remove it or mark it for removal while an array is active? For example, on an array used as the root filesystem, where stopping and restarting is a "take the machine down and boot from a live-cd" sort of affair. All of my arrays have the bbl enabled. It has never caused me an issue, but looking at it I can see how that might be possible.
Regards,
Brad
next prev parent reply other threads:[~2020-04-29 12:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 6:47 Does a "check" of a RAID6 actually read all disks in a stripe? Brad Campbell
2020-04-28 11:02 ` Brad Campbell
2020-04-28 13:47 ` Phil Turmel
2020-04-28 14:00 ` Brad Campbell
2020-04-28 14:41 ` Phil Turmel
2020-04-29 12:56 ` Brad Campbell [this message]
2020-04-28 15:40 ` Piergiorgio Sartor
2020-05-03 3:28 ` Brad Campbell
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=a1ebabac-6674-2907-55a6-41479c469232@fnarfbargle.com \
--to=lists2009@fnarfbargle.com \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.org \
/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.