From: Xiao Ni <xni@redhat.com>
To: Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
linux-raid <linux-raid@vger.kernel.org>
Cc: Jes Sorensen <jes.sorensen@redhat.com>,
tomasz.majchrzak@intel.com, aleksey.obitotskiy@intel.com,
pawel.baldysiak@intel.com
Subject: Re: The subarray is loaded container by load_container
Date: Wed, 27 Jul 2016 21:19:25 +0800 [thread overview]
Message-ID: <5798B4DD.6030702@redhat.com> (raw)
In-Reply-To: <4f57d953-8545-4647-49e7-c434e1892fb6@intel.com>
On 07/07/2016 06:16 PM, Artur Paszkiewicz wrote:
> On 07/07/2016 11:13 AM, Xiao Ni wrote:
>> Hi all
>>
>> We encountered one problem at booting time:
>>
>> Run MD devices: mdadm: array /dev/md/OSVOLUME0 now has 2 devices (0 new) [FAILED]
>>
>> mdadm -IRs returns 1 at the booting time. In fact the array is already running. The
>> command mdadm -IRs shouldn't return 1 if all the arrays are running, right?
>>
>> In IncrementalScan function, it scans all the raid in /run/mdadm/map. It contains the
>> subarray too. The return value is 1 from function load_container. So the return value
>> of IncrementalScan rv is set to 1. If all arrays are running already, I think mdadm -IRs
>> should return 0, not 1.
>>
>> Should we checks earlier whether it's a container or not before calling load_container?
>>
>> Best Regards
>> Xiao
>>
> Hi Xiao,
>
> I think you're right that mdadm -IRs should return 0 in this case.
> IncrementalScan should not try loading a container from a member array,
> because that will always fail. Can you check if this fixes the problem
> for you?
>
> diff --git a/Incremental.c b/Incremental.c
> index ba97b00..cc01d41 100644
> --- a/Incremental.c
> +++ b/Incremental.c
> @@ -1347,8 +1347,12 @@ restart:
>
> if (devnm && strcmp(devnm, me->devnm) != 0)
> continue;
> - if (devnm && me->metadata[0] == '/') {
> + if (me->metadata[0] == '/') {
> char *sl;
> +
> + if (!devnm)
> + continue;
> +
> /* member array, need to work on container */
> strncpy(container, me->metadata+1, 32);
> container[31] = 0;
>
> Thanks,
> Artur
>
> --
> 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
Hi Artur
Sorry for late response. I have been waiting the result from customer
and the customer haven't give me the answer. I tested this in my
environment and this patch can fix this problem.
Best Regards
Xiao
next prev parent reply other threads:[~2016-07-27 13:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1516157514.3880097.1467881964185.JavaMail.zimbra@redhat.com>
2016-07-07 9:13 ` The subarray is loaded container by load_container Xiao Ni
2016-07-07 10:16 ` Artur Paszkiewicz
2016-07-27 13:19 ` Xiao Ni [this message]
2016-08-04 18:38 ` Jes Sorensen
2016-08-09 8:05 ` Artur Paszkiewicz
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=5798B4DD.6030702@redhat.com \
--to=xni@redhat.com \
--cc=aleksey.obitotskiy@intel.com \
--cc=artur.paszkiewicz@intel.com \
--cc=jes.sorensen@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=pawel.baldysiak@intel.com \
--cc=tomasz.majchrzak@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).