All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: NeilBrown <neilb@suse.de>
Cc: Jon Nelson <jnelson-linux-raid@jamponi.net>,
	LinuxRaid <linux-raid@vger.kernel.org>
Subject: Re: can you help explain some --examine output to me?
Date: Sat, 20 Dec 2008 16:15:40 +0100	[thread overview]
Message-ID: <20081220151540.GA4109@rap.rap.dk> (raw)
In-Reply-To: <05e7e5a941b9af88462a85af4d4efc33.squirrel@neil.brown.name>

On Sat, Dec 20, 2008 at 12:16:01PM +1100, NeilBrown wrote:
> On Sat, December 20, 2008 11:34 am, Jon Nelson wrote:
> > As part of the output from --explain (on a raid1 with a 1.0 metadata),
> > I see this:
> >
> >     Array Slot : 3 (failed, failed, 0, 1)
> >    Array State : uU 2 failed
> >
> > I read the first line as "This device is using slot 3. slot 0 is
> > failed, slot 1 is failed, slot 2 is RaidDevice 0, slot 3 is RaidDevice
> > 1" where RaidDevice is the same as in the output for --detail. Is that
> > correct?
> >
> > The second line is more opaque. What to little-u and big-u mean? Does
> > "2 failed" mean the raid thinks two devices have failed?
> >
> 
> Yes, it is rather cryptic...
> 
> Every device in a 1.x array is assigned a 'slot' number.  This number is
> stable - it never changes.
> 
> Each device in the array also has a 'role' number indicating its current
> role in the array, which is either to be a spare or to have a position
> (0, 1, ...) in the array.
> 
> The output you produces says that this device occupies slot 3.
> It then notes that:
>   the device which occupied slot 0 has failed
>   the device which occupied slot 1 has failed
>   the device which occupies slot 2 has role 0
>   the device which occupies slot 3 has role 1
> 
> Then it shows you the state which indicated how the different
> roles are going.
>    uU
> means that both roles are 'up', and the 'this' device has the second
> role (capital U for 'this' device).
> Two devices have previously failed.
> 
> I should probably get rid of that '2 failed' bit, it isn't helpful.
> I should probably report 'empty' rather than 'failed' in the 'Array Slot'
> line.
> 
> Note that if you fail a devices, remove it, then add it back in such that
> it doesn't appear to be a re-add, it will be treated like a new
> device and get a new slot number.  (after all the old device was faulty,
> this one isn't so it must be a new device ?).
> I should probably get it to re-use the slot number in that case.
> 
> And I should probably document some of this.

Oh, well, you just did :-). I added this to the mdadm FAQ wiki page.

keld

      parent reply	other threads:[~2008-12-20 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-20  0:34 can you help explain some --examine output to me? Jon Nelson
2008-12-20  1:16 ` NeilBrown
2008-12-20  1:25   ` Jon Nelson
2008-12-20 15:15   ` Keld Jørn Simonsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081220151540.GA4109@rap.rap.dk \
    --to=keld@dkuug.dk \
    --cc=jnelson-linux-raid@jamponi.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.