* 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 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).