From: NeilBrown <neilb@suse.de>
To: Dan Williams <dan.j.williams@gmail.com>
Cc: Seblu <seblu@seblu.net>, linux-raid@vger.kernel.org
Subject: Re: Mdadm, udev and fakeraid?
Date: Sat, 23 Apr 2011 18:45:51 +1000 [thread overview]
Message-ID: <20110423184551.7bb437de@notabene.brown> (raw)
In-Reply-To: <BANLkTik6qpCx-Y=DXY6U6yu0habSohyiPw@mail.gmail.com>
On Fri, 22 Apr 2011 19:37:40 -0700 Dan Williams <dan.j.williams@gmail.com>
wrote:
> On Sun, Apr 17, 2011 at 5:38 PM, NeilBrown <neilb@suse.de> wrote:
> > As has been mentioned elsewhere, mdadm only recognised IMSM arrays on
> > machines with IMSM hardware. I'm not entirely happy about this and may well
> > change it.
>
> I have trouble answering the "least surprise" question in this area.
>
> Is it more surprising to go into your BIOS, explicitly turn off raid
> support and still see raid devices showing up?
Is the "RAID support has been explicitly turned off" state visible from a
running kernel? or is it indistinguishable from "platform does not have RAID
support"?
>
> Or is it more surprising to take a raid array from a raid enabled
> system to raid disabled system and wonder why things won't assemble?
>
> For safety I think it is better if mdadm not perform operations that
> might be incompatible with the platform option-rom. But if you need
> to recover to a usb attached drive, or some other
> platform-incompatible configuration, you can use the environment
> variable in a pinch.
There are 3 interesting cases: create, assemble, examine.
(grow might be interesting too, but for now it would be confusing).
I am perfectly happy for 'create' to be arbitrarily hard if platform support
is not available. One is unlikely to want to create an array in that case
anyway.
I think 'examine' should always show whatever it can, which is the case for
3.2.1. Possibly it should also give a warning about any difficulty that
might be experienced in assembling the array.
Assemble in the interesting case. The law of least surprise requires it to
either work or give a good error message. Your suggestion that it possibly
should not work in some cases seems defensible, so at least a very clear
error message would be good.
As for how to over-ride the default caution - I would prefer --force to
achieve it rather than requiring an environment variable. I would possibly
accept --force-platform (or similar) but I think --force should be sufficient.
What think you?
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-04-23 8:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-03 16:03 Mdadm, udev and fakeraid? Seblu
2011-04-05 6:20 ` NeilBrown
2011-04-15 14:15 ` Seblu
2011-04-16 5:27 ` Luca Berra
2011-04-18 0:38 ` NeilBrown
2011-04-22 11:24 ` Seblu
2011-04-23 2:37 ` Dan Williams
2011-04-23 8:45 ` NeilBrown [this message]
2011-04-26 6:06 ` Luca Berra
2011-04-24 22:44 ` Seblu
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=20110423184551.7bb437de@notabene.brown \
--to=neilb@suse.de \
--cc=dan.j.williams@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=seblu@seblu.net \
/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).