Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: Neil Brown <neilb@suse.de>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
	linux-raid@vger.kernel.org
Subject: Re: RAID grow and disk failure
Date: Sat, 26 Jun 2010 15:12:35 +0200	[thread overview]
Message-ID: <20100626131235.GA12127@lazy.lzy> (raw)
In-Reply-To: <20100625075751.4429f224@notabene.brown>

Hi,

> Assuming the code doesn't have any bugs, the reshape will stop, then
> immediately restart picking up where it left off.

thanks, that's what I wanted to know.

> You will of course end up with a degraded array

Yes, that was clear.

> It might be nice in these circumstances to abort the reshape and revert back
> the the previous number of devices - particularly if it was the new device
> that failed.  However that currently isn't supported.

Well, probably as an option, it could be interesting.

Actually, I would be still interested, we already
discussed the topic, on a RAID-5/6 with HDDs of
different size.
This would simplify many things...

> > 1)
> > mdadm --grow ...
> > mdadm --wait
> > pvresize
> 
> Yes.
> 
> > 
> > 2)
> > mdadm --grow
> > pvresize
> 
> No.
> Until the reshape has completed, the extra space is not available.

There seem to be an issue, here, maybe.

Using the command line:

mdadm --grow /dev/md/vol02 --bitmap=none; mdadm --grow /dev/md/vol02 -n 9 --backup-file=/var/tmp/md125.backup; mdadm --wait /dev/md/vol02; mdadm --grow /dev/md/vol02 --bitmap=internal --bitmap-chunk=128

Note that /dev/md/vol02 is the usual link to /dev/md125,
which should be the same for this scope, I guess.

I got (in two independent tests):

mdadm: Need to backup 2688K of critical section..
mdadm: failed to set internal bitmap.

Re-issuing:

mdadm --wait /dev/md/vol02; mdadm --grow /dev/md/vol02 --bitmap=internal --bitmap-chunk=128

Does wait.

Could it be the devices (being USB) are so slow
that some race condition is uncovered and the
immediate "--wait" after the "--grow" does not work?

Thanks,

bye,

-- 

piergiorgio

  reply	other threads:[~2010-06-26 13:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 18:12 RAID grow and disk failure Piergiorgio Sartor
2010-06-24 21:57 ` Neil Brown
2010-06-26 13:12   ` Piergiorgio Sartor [this message]
2010-06-28 23:49     ` 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=20100626131235.GA12127@lazy.lzy \
    --to=piergiorgio.sartor@nexgo.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox