Re: More Hot Unplug/Plug work

[Dan Williams <dan.j.williams@intel.com>]

On Wed, Apr 28, 2010 at 7:37 PM, Neil Brown <neilb@suse.de> wrote:
>> So something like DOMAIN spanning=imsm, to tell mdadm to follow imsm
>> rules for this domain.  Where 'spanning' is policy tag??
>>
>
> Thanks.
>
> So we have two different ideas here.
>
> 1/ A given set of devices (paths) are all attached to the one controller.
> 2/ A given array is not allowed to span controllers
>
> The first statement is somewhat similar to a statement about sparegroups.
> It groups devices together is some way.
>
> The second is a policy statement, and is metadata specific to some extent.
> If I create a native-metadata array using the controller, then adding other
> devices from a different controller is a non-issue.  It is only when an
> IMSM array is created that it is an issue (and then - only if the array is to
> be used for boot for for multi-boot).
>
> So the ARRAY line could have "exclusive-group=foo" where 'foo' is a group
> name similar to those used for 'spare-group='
> But that isn't much fun for auto-detect and auto-assembly.
>
> Maybe we want to extend the 'auto' line.  It gives policy on a per-metadata
> basis. Maybe:
>
>  POLICY auto-assemble  +1.x -all
>  POLICY same-group  imsm
>
> where 'same-group' means that all the devices in an array must be in the
> same spare-group.  The 'domain' lines assign spare-groups to devices.
>
> Maybe "same-group" could be "same-$tag" so we could have different tags
> for different metadatas....
>
> Is this working for anyone else, or have I lost the plot??
>

I am not grokking the separate POLICY line, especially for defining
the spare-migration border because that is already what DOMAIN is
specifying.

Here is what I think we need to allow for simple honoring of platform
constraints but without needing to expose all the nuances of those
constraints in config-file syntax... yet.

1/ Allow path= to take a metadata name this allows the handler to
identify its known controller ports, alleviating the user from needing
to track which ports are allowed, especially as it may change over
time.  If someone really wants to see which ports a metadata handler
cares about we could have a DOMAIN line dumped by --detail-platform
--brief -e imsm.  However for simplicity I would rather just dump:

DOMAIN path=imsm action=spare-same-port spare-migration=imsm

2/ I think we should always block configurations that cross domain
boundaries.  One can always append more path= lines to override this.

3/ The metadata handler may want to restrict/control where spares are
placed in a domain.  To enable interaction with CIM we are looking to
add a storage-pool id to the metadata.  The primary usage of this will
be to essentially encode a spare-group number in the metadata.  This
seems to require a spare-migration= option to the DOMAIN line.  By
default it is 'all' but it can be set to a metadata-name to let the
handler apply its internal migration policy.

That should cover everything I would like to expose  Comments?

--
Dan
--
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