linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).