Ok, dumb question time ...

Ok, dumb question time ...

[Joe Landman]

Not having much luck with this.  Let me explain ...

Imagine we have a RAID1 with 3 elements.  It was originally a RAID1 with 
2 elements, and we added a 3rd using

	mdadm /dev/md0 --add /dev/loop1

What I want to do is conceptually very simple.  I want to permanently 
remove loop1, without having the array become dirty, or degraded.  That 
is, I would like

	mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1

to result in a clean array with two members.

It doesn't.  The array is marked as being in the "clean, degraded" 
state.  Which, as it is the root file system array, has the unfortunate 
side effect of not allowing the RAID1 to properly assemble at boot (that 
degraded state).

So ... can I force the array to either remove the extra unneeded loop1 
device, and update its metadata properly ... or force it into a clean, 
active state without the loop1 device, or force the assembly on boot to 
occur regardless of what it thinks it should have?

This is quite disconcerting ... I thought it would be simple.
-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: landman@scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615

Re: Ok, dumb question time ...

[Neil Brown]

On Fri, 08 Oct 2010 00:20:35 -0400
Joe Landman <landman@scalableinformatics.com> wrote:

> Not having much luck with this.  Let me explain ...
> 
> Imagine we have a RAID1 with 3 elements.  It was originally a RAID1 with 
> 2 elements, and we added a 3rd using
> 
> 	mdadm /dev/md0 --add /dev/loop1
> 
> What I want to do is conceptually very simple.  I want to permanently 
> remove loop1, without having the array become dirty, or degraded.  That 
> is, I would like
> 
> 	mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
> 
> to result in a clean array with two members.
> 
> It doesn't.  The array is marked as being in the "clean, degraded" 
> state.  Which, as it is the root file system array, has the unfortunate 
> side effect of not allowing the RAID1 to properly assemble at boot (that 
> degraded state).
> 
> So ... can I force the array to either remove the extra unneeded loop1 
> device, and update its metadata properly ... or force it into a clean, 
> active state without the loop1 device, or force the assembly on boot to 
> occur regardless of what it thinks it should have?
> 
> This is quite disconcerting ... I thought it would be simple.

It is.

You want the array to think that it only has two devices?

  mdadm --grow /dev/md0 --raid-devices=2

Done.

NeilBrown

Re: Ok, dumb question time ...

[Joe Landman]

On 10/08/2010 12:54 AM, Neil Brown wrote:

>> This is quite disconcerting ... I thought it would be simple.
>
> It is.
>
> You want the array to think that it only has two devices?
>
>    mdadm --grow /dev/md0 --raid-devices=2

Very nice ... thanks!

Re: Ok, dumb question time ...

[CoolCold]

On Fri, Oct 8, 2010 at 8:20 AM, Joe Landman
<landman@scalableinformatics.com> wrote:
> Not having much luck with this.  Let me explain ...
>
> Imagine we have a RAID1 with 3 elements.  It was originally a RAID1 with 2
> elements, and we added a 3rd using
>
>        mdadm /dev/md0 --add /dev/loop1
>
> What I want to do is conceptually very simple.  I want to permanently remove
> loop1, without having the array become dirty, or degraded.  That is, I would
> like
>
>        mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
>
> to result in a clean array with two members.
>
> It doesn't.  The array is marked as being in the "clean, degraded" state.
>  Which, as it is the root file system array, has the unfortunate side effect
> of not allowing the RAID1 to properly assemble at boot (that degraded
> state).
Am I understanding right, you can't boot because that md array isn't
assembled at all or just assembled but degraded?
If first, are you happy Ubuntu user?
>
> So ... can I force the array to either remove the extra unneeded loop1
> device, and update its metadata properly ... or force it into a clean,
> active state without the loop1 device, or force the assembly on boot to
> occur regardless of what it thinks it should have?
>
> This is quite disconcerting ... I thought it would be simple.
> --
> Joseph Landman, Ph.D
> Founder and CEO
> Scalable Informatics, Inc.
> email: landman@scalableinformatics.com
> web  : http://scalableinformatics.com
>       http://scalableinformatics.com/jackrabbit
> phone: +1 734 786 8423 x121
> fax  : +1 866 888 3112
> cell : +1 734 612 4615
> --
> 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
>



-- 
Best regards,
[COOLCOLD-RIPN]
--
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: Ok, dumb question time ...

[Joe Landman]

On 10/08/2010 02:01 PM, CoolCold wrote:

>> It doesn't.  The array is marked as being in the "clean, degraded" state.
>>   Which, as it is the root file system array, has the unfortunate side effect
>> of not allowing the RAID1 to properly assemble at boot (that degraded
>> state).
> Am I understanding right, you can't boot because that md array isn't
> assembled at all or just assembled but degraded?
> If first, are you happy Ubuntu user?

Its not assembling due to the "degraded" state.  This is on Centos 5.5 
using our kernel bits (never had a problem with this before).  We've 
gotten past that issue and are now onto the next one for them (many 
thanks to Neil for the solution)

The customer in question may have modified their configs, and we are 
trying to walk their changes back to the point where it stopped working.

Thanks

Joe


-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman@scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615