From: Neil Brown <neilb@suse.de>
To: Kasper Sandberg <postmaster@metanurb.dk>
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 13:09:15 +1100 [thread overview]
Message-ID: <20091124130915.16305db2@notabene.brown> (raw)
In-Reply-To: <1259026597.31633.129.camel@localhost>
On Tue, 24 Nov 2009 02:36:37 +0100
Kasper Sandberg <postmaster@metanurb.dk> wrote:
> 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?
It isn't currently possible.
It would not be too hard to implement a conversion from 0.90 to 1.0
metadata, but I have not concrete plans to provide this.
NeilBrown
prev parent reply other threads:[~2009-11-24 2:09 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
2009-11-24 2:09 ` Neil Brown [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=20091124130915.16305db2@notabene.brown \
--to=neilb@suse.de \
--cc=goswin-v-b@web.de \
--cc=linux-raid@vger.kernel.org \
--cc=postmaster@metanurb.dk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox