From: Bill Davidsen <davidsen@tmr.com>
To: Jules Bean <jules@jellybean.co.uk>
Cc: David Greaves <david@dgreaves.com>, NeilBrown <neilb@suse.de>,
linux-raid@vger.kernel.org
Subject: Re: After partition resize, RAID5 array does not assemble on boot
Date: Fri, 06 Jun 2008 09:52:45 -0400 [thread overview]
Message-ID: <4849412D.9030607@tmr.com> (raw)
In-Reply-To: <48469523.4050601@jellybean.co.uk>
Jules Bean wrote:
> David Greaves wrote:
>>> 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'?
>
> Stress testing the disks by an md rebuild is a feature! It increases
> confidence that they work.
>
> ;)
>
> Seriously, I understand your point now. Yes, a rebuild-free partition
> resize would be a nice feature. So would a "help, please find my
> superblock by exhaustive scanning" utility ;)
Since this code must work when a partition is added on a totally new
drive, and when the partition is grown DOWN from the low end, clearly
the default must be a rebuild. And running "repair" before doing this
stuff is a really good idea!
What is needed is to do something like assume-clean on the old data and
a sync on the new chunks. I don't see that there is a remotely safe way
to do that, currently, although if you were willing to be unsafe you
could remove a partition, grow it at the "top" end, and reassemble with
--assume-clean. Sprinkling with holy water first might be a good thing.
I'm just thinking out loud here, there are probably good reasons why
this wouldn't work.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2008-06-06 13:52 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
2008-06-04 13:14 ` Jules Bean
2008-06-06 13:52 ` Bill Davidsen [this message]
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=4849412D.9030607@tmr.com \
--to=davidsen@tmr.com \
--cc=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.