linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: Dan Williams <dan.j.williams@intel.com>,
	"Labun, Marcin" <Marcin.Labun@intel.com>,
	Neil Brown <neilb@suse.de>,
	"Hawrylewicz Czarnowski,
	Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>,
	"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	Bill Davidsen <davidsen@tmr.com>
Subject: Re: Auto Rebuild on hot-plug
Date: Mon, 29 Mar 2010 14:57:36 -0400	[thread overview]
Message-ID: <4BB0F820.4030707@redhat.com> (raw)
In-Reply-To: <4BB0F32F.9030803@anonymous.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3566 bytes --]

On 03/29/2010 02:36 PM, John Robinson wrote:
> On 29/03/2010 19:10, Doug Ledford wrote:
> [...]
>> All of the above actions are related to domains that are degraded.  But
>> what to do if the array isn't degraded?  We could add the device as a
>> spare, but if the array isn't degraded, adding a new hot spare doesn't
>> really *do* anything.  No rebuild will start, nothing immediate happens,
>> it just goes in and sits there.  And now that we have all these fancy
>> grow options, it's not entirely clear that a user would want that
>> anyway.  So, I would argue that if the array isn't degraded, then there
>> is no sense of emergency in our actions, and there exists multiple
>> options for what to do with the device, some include being a hot spare
>> while others include using the device to grow the array, and the
>> possibilities and answers to what to do here are not at all clear.  Even
>> if the user had previously configured us to treat the device as a spare,
>> they may change their mind and want to grow things.  Given that there's
>> no immediate need to do anything as there aren't any degraded arrays, I
>> say let the user do whatever they want and don't try to do anything
>> automatically as it seems likely to me that the user's wants in this
>> area are likely to change from time to time based on circumstances and
>> having them update the config file prior to inserting the device is more
>> klunky than just telling them to do whatever they want themselves after
>> inserting the device.
> [...]
> 
> Yes, but do create the partition(s), boot sector, etc and set up the
> spare(s).

Really, we should never have to do this in the situation I listed: aka
no degraded arrays exist.  This implies that if you had a raid1 /boot
array, that it's still intact.  So partitioning and setting up boot
loaders doesn't make sense as the new disk isn't going in to replace
anything.  You *might* want to add it to the raid1 /boot, but we don't
know that so doing things automatically doesn't make sense.

> The user installed the system with anaconda or whatever, and
> may not know the incantations to partition his new disc or install a
> boot loader, so if he's managed to configure a mdadm.conf which says the
> spare slots in his RAID chassis should belong to mdadm, prepare them for
> him. Then all he needs to do is issue whatever grow command.
> 
> I think the exception to this is /boot on RAID-1, where I would prefer
> to be able to have the system automatically add the new partition as an
> active mirror instead of a hot spare, in case this new drive is what we
> have to boot off next time.

Again, I'm drawing a distinction here between a degraded array and a
non-degraded array.  If the current array isn't degraded, then we won't
be booting off the new drive next time unless the user goes into the
BIOS and sets the new drive as the active boot device.  And if the user
is going to do that, then they ought to be able to setup their new boot
mirror member themselves.

> I suppose there might be circumstances where you want to do something
> else, like Netgear do on their ReadyNAS, but while it might be nice to
> be able to configure that sort of automatic growing and reshaping, it
> doesn't belong in the default config.
> 
> Cheers,
> 
> John.


-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-03-29 18:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-25  0:35 Auto Rebuild on hot-plug Neil Brown
2010-03-25  2:47 ` Michael Evans
2010-03-31  1:18   ` Neil Brown
2010-03-31  2:46     ` Michael Evans
2010-03-25  8:01 ` Luca Berra
2010-03-31  1:26   ` Neil Brown
2010-03-31  6:10     ` Luca Berra
2010-03-25 14:10 ` John Robinson
2010-03-31  1:30   ` Neil Brown
2010-03-25 15:04 ` Labun, Marcin
2010-03-27  0:37   ` Dan Williams
2010-03-29 18:10     ` Doug Ledford
2010-03-29 18:36       ` John Robinson
2010-03-29 18:57         ` Doug Ledford [this message]
2010-03-29 22:36           ` John Robinson
2010-03-29 22:41             ` Dan Williams
2010-03-29 22:46               ` John Robinson
2010-03-29 23:35             ` Doug Ledford
2010-03-30 12:10               ` John Robinson
2010-03-30 15:53                 ` Doug Ledford
2010-04-02 11:01                   ` John Robinson
2010-03-29 21:36       ` Dan Williams
2010-03-29 23:30         ` Doug Ledford
2010-03-30  0:46           ` Dan Williams
2010-03-30 15:23             ` Doug Ledford
2010-03-30 17:47               ` Labun, Marcin
2010-03-30 23:47                 ` Dan Williams
2010-03-30 23:36               ` Dan Williams
2010-03-31  4:53               ` Neil Brown
2010-03-26  6:41 ` linbloke
2010-03-31  1:35   ` Neil Brown
2010-03-26  7:52 ` Majed B.
2010-03-31  1:42   ` 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=4BB0F820.4030707@redhat.com \
    --to=dledford@redhat.com \
    --cc=Marcin.Labun@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=davidsen@tmr.com \
    --cc=ed.ciechanowski@intel.com \
    --cc=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=przemyslaw.hawrylewicz.czarnowski@intel.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;
as well as URLs for NNTP newsgroup(s).