On Wed, Mar 31, 2010 at 12:26:22PM +1100, Neil Brown wrote:
On Thu, 25 Mar 2010 09:01:08 +0100
Luca Berra <bluca@xxxxxxxxxx> 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.
yes, i realize my comment was rude, sorry for that, but that comment on
the blog was imho just a troll.
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
I fully agree.
still room to improve mdadm to make it more powerful, more informative, and
more forgiving.
until it can read mail ;)
> 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.
I can think of two scenarios.
1) an encrypted device (without LUKS header)
2) a device where the metadata is corrupted, and we plugged it in an
hurry to attempt data recovery (oh, we were in an hurry and forgot about
the mdadm policy)
What i am scared of are distributions thinking it would be cool and
putting a non-strictly conservative policy as default.
> 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.
ah. ok, i tought you meant something real-time.
thinking about it, maybe something could be done using dbus...
we can also make /usr/bin/md-create-spare ...
Yes, there is a place for something like that certainly.
NeilBrown
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
