All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kasper Sandberg <postmaster@metanurb.dk>
To: Neil Brown <neilb@suse.de>
Cc: senthilkumar.muthukalai@wipro.com, goswin-v-b@web.de,
	linux-raid@vger.kernel.org
Subject: Re: RAID 5 rebuild fails with power interruption.
Date: Tue, 24 Nov 2009 02:36:37 +0100	[thread overview]
Message-ID: <1259026597.31633.129.camel@localhost> (raw)
In-Reply-To: <20091117094720.4c8736d7@notabene.brown>

On Tue, 2009-11-17 at 09:47 +1100, Neil Brown wrote:
> On Mon, 16 Nov 2009 16:00:38 +0530
> <senthilkumar.muthukalai@wipro.com> wrote:
> 
> > We face this problem in our NAS product where we handle RAID5.
> > In the below mentioned scenario, when RAID5 is rebuilding after
> > adding a disk, we reset the power.
> > Ideally when the system comes up, the RAID5 should have accepted the
> > disk but not in our case.
> > We get the 'kicking the non-fresh disk from array' message with the
> > boot message.
> > In our RAID init script we run 'mdadm -- Examine -- scan', followed by
> > 'mdadm --assemble'.
> > Could you pls help me to understand why this disk is being thrown out?
> 
> It is because the metadata being used (v0.90) does not have the ability
> to record that a device is partially recoverred.   It can only record
> that a device is either a full member of the array, or is not a member
> of the array.  So until the recovery completes, the metadata only
> records that the device is not a member of the array.  So when you
> restart, you find that the device is not a member of the array.
> 
> 
> > What could be the solution?
> 
> Use 1.x metadata.  e.g. add
>    --metadata=1.1
> to your --create command.
> 1.x metadata is able to record that a device is only partially
> recovered.  So when the array is restarted the device will be included
> and recovery will continue.

Might it be possible to upgrade metadata without having to recreate the
array?

> 
> NeilBrown

<snip>


  parent reply	other threads:[~2009-11-24  1:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-16  3:56 RAID 5 rebuild fails with power interruption senthilkumar.muthukalai
2009-11-16  5:19 ` Goswin von Brederlow
2009-11-16 10:30   ` senthilkumar.muthukalai
2009-11-16 22:47     ` Neil Brown
2009-11-17  6:30       ` senthilkumar.muthukalai
     [not found]         ` <20091118163655.2ef3f00d@notabene.brown>
     [not found]           ` <8338BD137FF1B64EB341218BD702985E02B43A2A@BLR-EC-MBX03.wipro.com>
2009-11-25  2:14             ` Neil Brown
2009-11-25 14:20               ` senthilkumar.muthukalai
2009-11-25 20:58                 ` Neil Brown
2009-11-26  6:26                   ` senthilkumar.muthukalai
     [not found]                     ` <200911260448.55466.tfjellstrom@shaw.ca>
2009-11-26 11:54                       ` senthilkumar.muthukalai
2009-11-24  1:36       ` Kasper Sandberg [this message]
2009-11-24  2:09         ` Neil Brown

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=1259026597.31633.129.camel@localhost \
    --to=postmaster@metanurb.dk \
    --cc=goswin-v-b@web.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=senthilkumar.muthukalai@wipro.com \
    /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.