* The subarray is loaded container by load_container
[not found] <1516157514.3880097.1467881964185.JavaMail.zimbra@redhat.com>
@ 2016-07-07 9:13 ` Xiao Ni
2016-07-07 10:16 ` Artur Paszkiewicz
0 siblings, 1 reply; 5+ messages in thread
From: Xiao Ni @ 2016-07-07 9:13 UTC (permalink / raw)
To: linux-raid
Cc: Jes Sorensen, tomasz.majchrzak, aleksey.obitotskiy,
pawel.baldysiak, artur.paszkiewicz
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The subarray is loaded container by load_container
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
0 siblings, 1 reply; 5+ messages in thread
From: Artur Paszkiewicz @ 2016-07-07 10:16 UTC (permalink / raw)
To: Xiao Ni, linux-raid
Cc: Jes Sorensen, tomasz.majchrzak, aleksey.obitotskiy, pawel.baldysiak
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: The subarray is loaded container by load_container
2016-07-07 10:16 ` Artur Paszkiewicz
@ 2016-07-27 13:19 ` Xiao Ni
2016-08-04 18:38 ` Jes Sorensen
0 siblings, 1 reply; 5+ messages in thread
From: Xiao Ni @ 2016-07-27 13:19 UTC (permalink / raw)
To: Artur Paszkiewicz, linux-raid
Cc: Jes Sorensen, tomasz.majchrzak, aleksey.obitotskiy, pawel.baldysiak
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The subarray is loaded container by load_container
2016-07-27 13:19 ` Xiao Ni
@ 2016-08-04 18:38 ` Jes Sorensen
2016-08-09 8:05 ` Artur Paszkiewicz
0 siblings, 1 reply; 5+ messages in thread
From: Jes Sorensen @ 2016-08-04 18:38 UTC (permalink / raw)
To: Artur Paszkiewicz
Cc: Xiao Ni, linux-raid, tomasz.majchrzak, aleksey.obitotskiy,
pawel.baldysiak
Xiao Ni <xni@redhat.com> writes:
> On 07/07/2016 06:16 PM, Artur Paszkiewicz wrote:
>> 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.
Artur,
Do you have a version of this patch you would like me to apply to the
official mdadm tree?
Cheers,
Jes
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The subarray is loaded container by load_container
2016-08-04 18:38 ` Jes Sorensen
@ 2016-08-09 8:05 ` Artur Paszkiewicz
0 siblings, 0 replies; 5+ messages in thread
From: Artur Paszkiewicz @ 2016-08-09 8:05 UTC (permalink / raw)
To: Jes Sorensen
Cc: Xiao Ni, linux-raid, tomasz.majchrzak, aleksey.obitotskiy,
pawel.baldysiak
On 08/04/2016 08:38 PM, Jes Sorensen wrote:
> Do you have a version of this patch you would like me to apply to the
> official mdadm tree?
Hi Jes,
Yes I do, I'll send the patch in a moment.
Artur
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-08-09 8:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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
2016-08-04 18:38 ` Jes Sorensen
2016-08-09 8:05 ` Artur Paszkiewicz
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.