Ok, dumb question time ...

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

On Fri, 08 Oct 2010 00:20:35 -0400
Joe Landman 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
--
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 ...

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!

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

On Fri, Oct 8, 2010 at 8:20 AM, Joe Landman
wrote:
> Not having much luck with this. =A0Let me explain ...
>
> Imagine we have a RAID1 with 3 elements. =A0It was originally a RAID1=
with 2
> elements, and we added a 3rd using
>
> =A0 =A0 =A0 =A0mdadm /dev/md0 --add /dev/loop1
>
> What I want to do is conceptually very simple. =A0I want to permanent=
ly remove
> loop1, without having the array become dirty, or degraded. =A0That is=
, I would
> like
>
> =A0 =A0 =A0 =A0mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
>
> to result in a clean array with two members.
>
> It doesn't. =A0The array is marked as being in the "clean, degraded" =
state.
> =A0Which, as it is the root file system array, has the unfortunate si=
de 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 loop=
1
> 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 =A0: http://scalableinformatics.com
> =A0 =A0 =A0 http://scalableinformatics.com/jackrabbit
> phone: +1 734 786 8423 x121
> fax =A0: +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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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 ...

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