linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Martin Wilck <mwilck@arcor.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Strange / inconsistent behavior with mdadm -I -R
Date: Mon, 18 Mar 2013 10:35:10 +1100	[thread overview]
Message-ID: <20130318103510.45bdd4a8@notabene.brown> (raw)
In-Reply-To: <51422D10.3040000@arcor.de>

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Thu, 14 Mar 2013 21:03:28 +0100 Martin Wilck <mwilck@arcor.de> wrote:

> Hello Neil,
> 
> for my DDF/RAID10 work, I have been trying to figure out how mdadm -I -R
> is supposed to behave, and I have found strangeness I'd like to clarify,
> lest I make a mistake in my DDF/RAID10 code.
> 
> My test case is incremental assembly of a clean array running mdadm -I
> -R by hand for each array device in turn.
> 
> 1) native md and containers behave differently for RAID 1
> 
> Both native and container RAID 1 are started in auto-read-only mode when
> the 1st disk is added. When the 2nd disk is added, the native md
> switches to "active" and starts a recovery which finishes immediately.
> Container arrays (tested: DDF), on the other hand, do not switch to
> "active" until a write attempt is made on the array. The problem is in
> the native case: after the switch to "active", no more disks can be
> added any more ("can only add $DISK as a spare").
> 
> IMO the container behavior makes more sense and matches the man page
> better than the native behavior. Do you agree? Would it be hard to fix that?

Without -R, the array should remain inactive until all expected devices have
been found.  Then it should switch:
  to 'active' if the array is known to this host - i.e. listed
       in /etc/mdadm.conf or has the right hostname in the metadata
  to 'read-auto' if the array is not known to this host.

With -R, it only stays inactive until we have the minimum devices needed for
a functioning array.  Then it will switch to 'read-auto' or, if the array is
known and all expected devices are present, it will switch to 'active'.

I think this is correct behaviour.  However I'm not quite sure from your
description whether you are saying that it doesn't behave like this, or if
you are saying that it does but it should behave differently.

Maybe if you could provide a sequence of "mdadm" commands that produces an
outcome different to what you would expect - that would reduce the chance
that I get confused.

> 
> 2) RAID1 skips recovery for clean arrays, RAID10 does not
> 
> Native RAID 10 behaves similar to RAID1 as described above. When the
> array can be started, it does so, in auto-read-mode. When the next disk
> is added after that, recovery starts, and the array switches to
> "active", and further disks can't be added the "simple way" any more.
> There's one important difference: in the RAID 10 case, the recovery
> doesn't finish immediately. Rather, md does a full recovery of the added
> disk although it was clean. This is wrong; I have come up with a patch
> for this which I will send in a follow-up email.
> 

I agree with your assessment here and with your patch, thanks.

NeilBrown



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  parent reply	other threads:[~2013-03-17 23:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 20:03 Strange / inconsistent behavior with mdadm -I -R Martin Wilck
2013-03-14 20:11 ` [PATCH] RAID10: Allow skipping recovery when clean arrays are assembled mwilck
2013-03-17 23:06   ` NeilBrown
2013-03-17 23:35 ` NeilBrown [this message]
2013-03-19 18:29   ` Strange / inconsistent behavior with mdadm -I -R Martin Wilck
2013-03-21  1:22     ` NeilBrown
2013-03-27  5:53       ` NeilBrown
2013-03-27 20:29         ` Martin Wilck
2013-04-16 19:09         ` Martin Wilck
2013-03-19 18:35   ` [PATCH] RAID10: Allow skipping recovery when clean arrays are assembled mwilck
2013-03-19 23:46     ` NeilBrown

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=20130318103510.45bdd4a8@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=mwilck@arcor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).