RE: [PATCH 1/5] FIX: set delta_disks to 0 for raid5->raid0 transition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: NeilBrown [mailto:neilb@xxxxxxx]
> Sent: Tuesday, February 15, 2011 9:58 AM
> To: Kwolek, Adam
> Cc: linux-raid@xxxxxxxxxxxxxxx; Williams, Dan J; Ciechanowski, Ed;
> Neubauer, Wojciech
> Subject: Re: [PATCH 1/5] FIX: set delta_disks to 0 for raid5->raid0
> transition
> 
> On Tue, 15 Feb 2011 08:30:22 +0000 "Kwolek, Adam"
> <adam.kwolek@xxxxxxxxx>
> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: NeilBrown [mailto:neilb@xxxxxxx]
> > > Sent: Tuesday, February 15, 2011 1:32 AM
> > > To: Kwolek, Adam
> > > Cc: linux-raid@xxxxxxxxxxxxxxx; Williams, Dan J; Ciechanowski, Ed;
> > > Neubauer, Wojciech
> > > Subject: Re: [PATCH 1/5] FIX: set delta_disks to 0 for raid5->raid0
> > > transition
> > >
> > > On Mon, 14 Feb 2011 14:12:49 +0100 Adam Kwolek
> <adam.kwolek@xxxxxxxxx>
> > > wrote:
> > >
> > > > We have to set proper value of delta_disks to avoid it wrongly
> being
> > > set
> > > > when it value remains UnSet for this level transition
> (Grow.c:1224).
> > > >
> > > > This causes too small value set to "raid_disks" in sysfs
> > > > and reshape raid5->raid0 fails.
> > > >
> > > > Signed-off-by: Adam Kwolek <adam.kwolek@xxxxxxxxx>
> > > > ---
> > > >
> > > >  Grow.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/Grow.c b/Grow.c
> > > > index 424d489..dba2825 100644
> > > > --- a/Grow.c
> > > > +++ b/Grow.c
> > > > @@ -1073,6 +1073,7 @@ char *analyse_change(struct mdinfo *info,
> > > struct reshape *re)
> > > >  		switch (info->new_level) {
> > > >  		case 0:
> > > >  			delta_parity = -1;
> > > > +			info->delta_disks = 0;
> > > >  		case 4:
> > > >  			re->level = info->array.level;
> > > >  			re->before.data_disks = info->array.raid_disks
> - 1;
> > >
> > > I think we have different expectations about what a RAID5 -> RAID0
> > > transition
> > > means.
> > >
> > > To me, it means getting rid of the parity information.  So a 4-
> device
> > > RAID5
> > > is converted to a 3-device RAID0 and stays the same size.
> > >
> > > I think you want it to maintain the same number of devices, so a 4-
> > > device
> > > RAID5 becomes a 4-device RAID0 and thus has larger storage.
> > >
> > > If you want that, you need to say:
> > >    mdadm -G /dev/md/xxx --level=0 --raid-disks=4
> > >
> > > I'd be happy with functionality to do:
> > >
> > >    mdadm -G /dev/md/xxx --level=0 --raid-disks=nochange
> > >
> > > or something like that so it could be easily scripted easily, but I
> > > want the
> > > default to do the simplest possible change.
> > >
> > > Am I correct about your expectations?
> >
> > Yes you are right.
> > Working in the way you described above, will probably need a change
> in md or mdadm should degrade array after reshape (before takeover).
> > If I recall takeover code correctly, to execute takeover from
> raid4/5->raid0, raid4/5 has to be a degraded array.
> > This a reason I've make no changes to raid_disks number, as such
> behavior seams fit current implementation.
> >
> > Please let me know the direction you think we should go.
> >
> 
> I don't understand....
> Working "the way I described" is just a slightly different way that
> arguments
> passed to mdadm are interpreted.  The underlying process can still
> happen
> exactly the same way - you just have to ask for it slightly
> differently.  No
> change in md or mdadm required.
>
> In any case, care is required if the RAID5 array goes degraded before
> you
> switch it to RAID0.  The sensible thing would probably be to leave it
> in
> RAID4 as the final switch to RAID0 would effectively destroy all your
> data.
> I suspect the kernel wouldn't allow the final switch if the RAID5 were
> degraded.

Look raid0.c:586, raid5 cannot be takeovered to raid0 if it is not degraded.
Parity disk (in raid4) has to be "virtual". 
In situation when we want to throw away parity disk, we have to make array degraded first or change md behavior (imho).

> The direction that I want to go is exactly as stated above.  If no
> explicit
> request is made to set the new value for raid-disks, then the change
> made
> should be the simplest possible - leaving the number of data-disks
> unchanged.
> 
> NeilBrown

I wanted to maintain the same number of devices due to IMSM compatibility.
It there are 2 arrays in container, number of devices in array cannot be changed in one array only.
I wanted to avoid different command behavior depending on arrays number in container.
This can make user confused, so I've decided to keep raid_disks without change.

BR
Adam




--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux