All of lore.kernel.org
 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 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.