linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Luca Berra <bluca@comedia.it>
Cc: linux-raid@vger.kernel.org
Subject: Re: Auto Rebuild on hot-plug
Date: Wed, 31 Mar 2010 12:26:22 +1100	[thread overview]
Message-ID: <20100331122622.7c43ca88@notabene.brown> (raw)
In-Reply-To: <20100325080108.GB20583@maude.comedia.it>

On Thu, 25 Mar 2010 09:01:08 +0100
Luca Berra <bluca@comedia.it> wrote:

> On Thu, Mar 25, 2010 at 11:35:43AM +1100, Neil Brown wrote:
> >
> >       http://blogs.techrepublic.com.com/opensource/?p=1368
> >
> > The most significant thing I got from this was a complain in the comments
> > that managing md raid was too complex and hence error-prone.
> 
> well, i would not be upset by j. random jerk complaining in a blog
> comments, as soon as you make it one click you will find another one
> that complains because it is not is favorite colour :P

We can learn something from any opinion that different from our own.

It is clear to me that using mdadm requires a certain level of understanding
to be used effectively and safely.
I don't think that can be entirely address in mdadm: there is a place of a
higher level framework that encodes policies and gives advice.  But there is
still room to improve mdadm to make it more powerful, more informative, and
more forgiving.

> 
> > I see the issue as breaking down in to two parts.
> >  1/ When a device is hot plugged into the system, is md allowed to use it as
> >     a spare for recovery?
> >  2/ If md has a spare device, what set of arrays can it be used in if needed.
> >
> > A typical hot plug event will need to address both of these questions in
> > turn before recovery actually starts.
> >
> > Part 1.
> >
> >  A newly hotplugged device may have metadata for RAID (0.90, 1.x, IMSM, DDF,
> >  other vendor metadata) or LVM or a filesystem.  It might have a partition
> >  table which could be subordinate to or super-ordinate to other metadata.
> >  (i.e. RAID in partitions, or partitions in RAID).  The metadata may or may
> >  not be stale.  It may or may not match - either strongly or weakly -
> >  metadata on devices in currently active arrays.
> also the newly hotplugged device may have _data_ on it.
>

You mean completely raw data, no partitions, no filesystem structure etc?
Yes, that is possible.  People who are likely to handle devices like that
would choose more conservative configurations.

 
> >  Some how from all of that information we need to decide if md can use the
> >  device without asking, or possibly with a simple yes/no question, and we
> >  need to decide what to actually do with the device.
> how does the yes/no question part work?

I imagine an Email to the admin "Hey boss, I just noticed you plugged in a
drive that looks like it used to be part of some array.  We need a spare on
this other array and the new device is big enough.  Shall I huh huh huh?  Go
on let me..."

Then the admin can choose to run the command "make it so", or not.


> we can also make /usr/bin/md-create-spare ...

Yes, there is a place for something like that certainly.

NeilBrown

  reply	other threads:[~2010-03-31  1:26 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 [this message]
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
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=20100331122622.7c43ca88@notabene.brown \
    --to=neilb@suse.de \
    --cc=bluca@comedia.it \
    --cc=linux-raid@vger.kernel.org \
    /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).