All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Jules Bean <jules@jellybean.co.uk>
Cc: NeilBrown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: After partition resize, RAID5 array does not assemble on boot
Date: Wed, 04 Jun 2008 12:51:11 +0100	[thread overview]
Message-ID: <484681AF.8030004@dgreaves.com> (raw)
In-Reply-To: <4846529B.1000809@jellybean.co.uk>

Jules Bean wrote:
> David Greaves wrote:
> Just add it as a fresh component. The old SB is irrelevant.
> 
> 1. Fail component
> 2. remove component
> 3. resize partition
> 4. FORCE KERNEL TO NOTICE NEW SIZE (that's what I got wrong!). Reboot is
> safest.
> 5. add component as new


> 6. watch as md layer rebuilds
And that's the bit that shouldn't be needed :)

Otherwise you're 'just' replacing devices one at a time which isn't very
interesting.

> Of course this does assume your RAID level has the redundancy required
> to remove a component (i.e. not RAID0).
Neil, would the sb-move approach support RAID0?

>> in step 4 mdadm may want to call the reread pt ioctl (which is what
>> blockdev --rereadpt does)
> 
> Seems to me that whilst cfdisk makes no visible attempt, plain 'fdisk'
> does try to call this ioctl but nonetheless it doesn't work if some
> other partition on that disk is busy (e.g. involved in some other md
> device, or mounted elsewhere). I saw messages to this effect whilst
> experimenting with different partition sizes looking for my missing
> superblock.
I read (http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/4319.html) there
are some ioctls that work even when some disk partitions are still in use
(providing there is no impact).
However I couldn't see them in the block-layer ioctls or any code in
fs/partitions/check.c

>> This approach, it seems to me, would avoid any reconstruction and
>> would be a
>> 'safer' way to grow the components.
> 
> It would avoid reconstruction which is good for the impatient.
> 
> I don't really see that it's "safer" though. I would have thought it was
> quicker but potentially less safe.

Avoiding a lot of time stress testing the disks in degraded mode isn't 'safer'?

David


  reply	other threads:[~2008-06-04 11:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  6:49 After partition resize, RAID5 array does not assemble on boot Jules Bean
2008-06-03 21:19 ` Jules Bean
2008-06-03 21:27   ` NeilBrown
2008-06-04  6:31     ` Jules Bean
2008-06-04  6:36       ` Peter Rabbitson
2008-06-04  7:58       ` David Greaves
2008-06-04  8:30         ` Jules Bean
2008-06-04 11:51           ` David Greaves [this message]
2008-06-04 13:14             ` Jules Bean
2008-06-06 13:52               ` Bill Davidsen
2008-06-06 14:42                 ` David Greaves
2008-06-06 14:46                   ` Jules Bean
2008-06-12  3:59             ` Neil Brown
2008-06-03 21:46   ` Peter Rabbitson

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=484681AF.8030004@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=jules@jellybean.co.uk \
    --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.