[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] EVMS 2.2.0-pre2: Removing active MD RAID-1 segment ?
From:       Kevin Corry <kevcorry () us ! ibm ! com>
Date:       2003-10-27 16:12:36
[Download RAW message or body]

On Monday 27 October 2003 09:58, Michel Bouissou wrote:
> Le Lundi 27 Octobre 2003 16:45, Kevin Corry a écrit :
> > I thought we still had a "mark faulty" option for raid-1, which would
> > kick an active member out of a raid-1 array, leaving the array degraded.
> > I'll have to ask Mike about it.
>
> I haven't seen such an option...

Mike just told me that the "mark faulty" option currently works for raid-5, 
but not raid-1. He is looking into adding that option for raid-1 objects.

> > > Related issue: After having fiddled around with my system for
> > > upgrading, and suffered from kernel problems, my system now thinks that
> > > the "primary" segment (unit 0) of my RAID-1 sets resides on my 2nd HD,
> > > and that the "secondary" segment (unit 1) resides on my 1st HD.
> > >
> > > How can I reverse this, so segments "0" are on the 1st HD, and segments
> > > "1" are on the 2nd HD ?
> >
> > This seems quite odd. The ordering of the raid-1 child objects should not
> > have changed while upgrading from evms 1.x to 2.x. Again, I'll have to
> > ask Mike for more info.
>
> It's not the upgrade itself that caused the problem, but my kernel
> problems. At a time, my system could see only my 2nd HD, so the first HD
> was kicked out of the RAID sets, leaving the 2nd HD running alone.
>
> Once after the 1st HD was back, I had to manually kick the "faulty"
> segments of the 1st HD out of RAID, then reinsert them to get them resync.
>
> This caused that now segments from the 2nd HD appear as first in the RAID-1
> sets, and I don't know how I could possibly reverse this...

Ok...that makes a little more sense. Honestly, this is kind of a non-issue. 
RAID doesn't actually have any notion of a "primary" member. Each active 
child object is treated equally. If a child dies and a spare child is 
activated in its place, the data could be sync'd from any of the remaining 
active child objects.

If the ordering really bugs you, when Mike gets the "mark faulty" option 
added, you could mark the new "0" segment faulty, remove it, and add it back 
as a spare. This might force the child objects to be reordered again, just as 
they were while you were upgrading. Of course, you'll be running degraded for 
a short time if you do this.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel

[prev in list] [next in list] [prev in thread] [next in thread]