linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [mdadm git pull] "--assemble --scan" support for imsm
Date: Thu, 30 Oct 2008 14:42:34 +1100	[thread overview]
Message-ID: <18697.11562.810718.957829@notabene.brown> (raw)
In-Reply-To: message from Dan Williams on Wednesday October 29

On Wednesday October 29, dan.j.williams@intel.com wrote:
> 
> What about container=<container uuid> as we can never really discern
> with certainty the name of the container device at
> ->brief_examine_super() time?

Yes, could do that.  It feels a bit ugly, but it probably makes sense.

But I've had another look at your 'provisional' thing and understand it
better and want to suggest some enhancements (Which might look like a
complete rewrite, but the important part of noticing the problem is
still yours :-)

You call Incremental_container from Assemble and that really isn't
right.  Each call to 'Assemble'  should assemble just one array, but
Incremental_container might assemble several.

Assemble() has the following basic structure:

 1/ walk through list of available devices determining which ones
    match the 'identity' of the required array.
 2/ Check the set of devices for consistency and make any updates that
    have been requested
 3/ Assemble the array from the selected devices, and start it.

With a slight variation for the 'auto-assemble' case wherein the
'identity' to match is taken from the first device that is found to be
part of an array that is not already assembled.

To fit the assembly of a specific member of a container into this
model, we need to have the 'container' in the list of available
devices.
If the identity specifies 'container=whatever' then we clearly select
all devices which match that.  You would expect at exactly one - the
container.  You would then need to call ->container_content on that
container and find the correct member array which matches the
'member=' specifier (or any other specifier there might be?)

Exactly how updates and "--force" are passed though would need to be
sorted out.
Then the devices in the selected array from ->container_content could
be passed to sysfs_add_disk and the array started.

Auto-assembly would discover that the first unused-so-far device was a
container, and would need to load the list of arrays and assemble the
first one that was not yet assembled.

I think that is the 'right' thing to do, but it seems like a lot of
work just for now, so I might leave it for a while and see if
something else occurs to me.

Thanks,
NeilBrown

  reply	other threads:[~2008-10-30  3:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 21:44 [mdadm git pull] "--assemble --scan" support for imsm Dan Williams
2008-10-29  9:19 ` Neil Brown
2008-10-29 16:12   ` Dan Williams
2008-10-30  3:42     ` Neil Brown [this message]
2008-11-02 23:15       ` Dan Williams
2008-11-04 10:52         ` Neil Brown
2008-11-05 15:40           ` Dan Williams
2008-10-30 12:43   ` Neil Brown
     [not found] <4C69D525.4060404@gmail.com>
2010-08-17 16:49 ` Dan Williams
2010-08-17 18:48   ` Jiang, Dave

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=18697.11562.810718.957829@notabene.brown \
    --to=neilb@suse.de \
    --cc=dan.j.williams@intel.com \
    --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).