From: Phil Turmel <philip@turmel.org>
To: "Peckins, Steven E" <speckins@illinois.edu>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: RAID6 recovery with 6/9 drives out-of-sync
Date: Wed, 1 Jun 2016 08:06:58 -0400 [thread overview]
Message-ID: <574ECFE2.9050602@turmel.org> (raw)
In-Reply-To: <5D9C8773-D76E-409F-8961-41EB3ACD177A@illinois.edu>
On 06/01/2016 07:32 AM, Peckins, Steven E wrote:
>
> On May 31, 2016, at 2:19 PM, Phil Turmel <philip@turmel.org> wrote:
>
>> On 05/30/2016 10:43 PM, Peckins, Steven E wrote:
>>>
>>> The component devices in the array are supposed to be multipath devices (dm-multipath), but for some reason, when the server was restarted, md grabbed both dm-* components and raw devices. I *think* that this is what caused the problem.
>>
>> Quite possible. You probably need a DEVICES clause in your mdadm.conf
>> to exclude the raw devices from the arrays.
>
> I had a typo in the DEVICE glob for the system disks (/dev/sd[ab]* instead of /dev/sd[ab][12]).
Understood, but be aware that if you have to hotswap one of these system
devices, they may not get the sda or sdb name, preventing a re-add or a
replacement from joining the array.
Since you are having to use /dev/mapper entries for some arrays,
consider using /dev/disk/by*/ symlinks for your system arrays.
>>> I'm seeking advice on how to proceed at this point. If more information is required, please ask.
>>
>> Hmmm. The partial success on mdadm --force suggests trying that again.
>> Possible with --force twice on the command line.
>>
>> Forced assembly is precisely what you need -- don't despair and attempt
>> anything else.
>
> Repeating the command was not successful; it is still reporting "/dev/md10 assembled from 5 drives and 1 spare - not enough to start the array." Four drives are listed as “possibly out of date." I assume those are the four that are not being incorporated.
>
> Output from --assemble --force 1x and 2x: http://pastebin.com/k1dT2zYC
{ In the future, please paste these in-line so the archives will have
them. The size limit for this list is ~ 100k. }
I vaguely recall a bug in forced reassembly for many out-of-date drives.
Please clone and build the latest mdadm userspace[1] and run that mdadm
binary for the forced assembly. Also show the portion of dmesg that
corresponds to the attempt.
Phil
[1] https://github.com/neilbrown/mdadm
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-06-01 12:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 2:43 RAID6 recovery with 6/9 drives out-of-sync Peckins, Steven E
2016-05-31 19:19 ` Phil Turmel
2016-06-01 11:32 ` Peckins, Steven E
2016-06-01 12:06 ` Phil Turmel [this message]
2016-06-01 13:16 ` Peckins, Steven E
2016-06-01 13:22 ` 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=574ECFE2.9050602@turmel.org \
--to=philip@turmel.org \
--cc=linux-raid@vger.kernel.org \
--cc=speckins@illinois.edu \
/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.