RE: [PATCH] FIX: Cannot continue reshape if incremental assembly isused

On Wed, Sep 07, 2011 4:38 AM Neil Brown wrote:
>
> On Tue, 6 Sep 2011 14:34:42 -0700 Dan Williams
> wrote:
>
> > On Thu, Sep 1, 2011 at 6:18 AM, Lukasz Dorau
> wrote:
> > > Description of the bug:
> > > Interrupted reshape cannot be continued using incremental assembly.
> > > Array becomes inactive.
> > >
> > > Cause of the bug:
> > > Reshape tried to continue with insufficient number of disks
> > > added by incremental assembly (tested using capacity expansion).
> > >
> > > Solution:
> > > During reshape adding disks to array should be blocked until
> > > minimum required number of disks is ready to be added.
> >
> > Can you provide a script test-case to reproduce the problem?
>
> I can:
>
> mdadm -C /dev/md/imsm -e imsm -n 4 /dev/sd[abcd]
> mdadm -C /dev/md/r5 -n3 -l5 /dev/md/imsm -z 2000000
> mdadm --wait /dev/md/r5
> mdadm -G /dev/md/imsm -n4
> sleep 10
> mdadm -Ss
> mdadm -I /dev/sda
> mdadm -I /dev/sdb
> mdadm -I /dev/sdc
>
> array is started and reshape continues.
>
> The problem is that container_content reports that array.working_disks is 3
> rather than 4.
> 'working_disks' should be the number of disks int the array that were working
> last time
> the array was assembled.
> However the imsm code only counts devices that can currently be found.
> I'm not familiar enough with the IMSM metadata to fix this.
> However by looking at the metadata on just one device in an array it should be
> possible
> to work out how many were working last time, and report that count.
>

Neil, please consider the following script test-case (not 4 but 5 drives finally in the array):

mdadm -C /dev/md/imsm -e imsm -n 5 /dev/sd[abcde]
mdadm -C /dev/md/r5 -n3 -l5 /dev/md/imsm -z 2000000
mdadm --wait /dev/md/r5
mdadm -G /dev/md/imsm -n5
sleep 10
mdadm -Ss
mdadm -I /dev/sda
mdadm -I /dev/sdb
mdadm -I /dev/sdc
# array is not started and reshape does not continue!
mdadm -I /dev/sdd

and now array is started and reshape continues - the minimum required number of disks is added to array already.

So the question is: when mdadm should start the array using incremental assembly?:
1) when minimum required number of disks is added and (degraded) array can be started or
2) when all disks that were working last time the array was assembled are added.

If the second is true, there is another question: when to decide to give up waiting for non-present disks that can be (e.g.) removed meanwhile by user?

What do you suggest?

Regards,
Lukasz

------------------------------------------------------------ ---------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku,
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
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

Re: [PATCH] FIX: Cannot continue reshape if incremental assembly isused

--Sig_/fdG.T77/vwWYnWf+lY+Kzqh
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 7 Sep 2011 21:42:28 -0700 "Williams, Dan J"
wrote:

> On Sep 7, 2011 6:26 PM, "NeilBrown" wrote:
> >
> > On Wed, 7 Sep 2011 18:11:12 -0700 "Williams, Dan J"
> > wrote:
> >
> > > On Wed, Sep 7, 2011 at 6:21 AM, Dorau, Lukasz
> wrote:
> > > Hmm, this might just be cribbed from the initial DDF implementation,
> > > should be straightforward to reuse the count we use for
> > > container_enough, but I'm not seeing where Incremental uses
> > > working_disks for external arrays...
> >
> > Assemble.c: assemble_container_content()
> > ....
> > if (runstop > 0 ||
> > (working + preexist + expansion) >=3D
> > content->array.working_disks) {
> > ....
> >
>=20
> ...so now i'd like to kill ->container_enough, because similar to the
> MD_SB_INVALID suggestion it's probably better to let ->container_content
> flag the true state rather than some sideband "don't call
> ->container_content yet" mechanism.

(catching up on some old mail).

I would be happy with that.

I don't exactly object to ->container_enough as it is conceivable that the
container knows something about the whole that you cannot deduce from the
member arrays.
But we definitely to want working_disks to be accurate so that we don't just
trust container_enough.

Thanks,
NeilBrown

--Sig_/fdG.T77/vwWYnWf+lY+Kzqh
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iD8DBQFOduP5G5fc6gV+Wb0RAs1ZAKCzAwXSdsz+dtrqEfMDXkVKMrGMaACg uCX+
v/Z7xXOh9dI4M9r2TLttqeA=
=NTq0
-----END PGP SIGNATURE-----

--Sig_/fdG.T77/vwWYnWf+lY+Kzqh--
--
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