On Thu, Mar 25, 2010 at 8:04 AM, Labun, Marcin [off-list ref] wrote:

I think that metadata keyword can be used to identify scope of devices to which the DOMAIN line applies.
For instance we could have:
DOMAIN path=glob-pattern metadata=imsm hotplug=mode1  spare-group=name1
DOMAIN path=glob-pattern metadata=0.90 hotplug=mode2  spare-group=name2

Keywords:
Path, metadata and spare-group shall define to which arrays the hotplug definition (or other definition of action) applies. User could define any subset of it.
For instance to define that all imsm arrays shall use hotplug mode2 user shall define:
DOMAIN metadata=imsm hotplug=mode2

In above example user need not define spare-group in his/her configuration file for each array.

I also assume that each metadata handler can additionally sets its own rules of accepting the spare in the container. Rules can be derived from platform dependencies or metadata. Notice that user can disable platform specific constrains by defining IMSM_NO_PLATFORM environment variable.

For the 'platform' case we could automate some decisions, but I think
I would rather extend the --detail-platform option to dump the
recommended/compatible DOMAIN entries for the platform, perhaps via
the --brief modifier.  This mirrors what can be done with --examine
--brief to generate an initial configuration file that can be modified
to taste.

quoted

  hotplug modes are:
    none  - ignore any hotplugged device
    incr  - normal incremental assembly (the default).  If the device has
         metadata that matches an array, try to add it to the array
    replace - If above fails and a device was recently removed from this
         same path, add this device to the same array(s) that the old
devices
         was part of
    include - If the above fails and the device has not recognisable
metadata
         add it to any array/container that uses devices in this domain,
         partitioning first if necessary.
    force - as above but ignore any pre-existing metadata


  I'm not sure that all those are needed, or are the best names.  Names
like
    ignore, reattach, rebuild, rebuild_spare
  have also been suggested.

Please consider:
     spare_add - add any spare device that matches the metadata container/volume in case of native metadata regardless of array state, so later such a spare can be used in rebuild process.

This is the same as 'incr' above.  If the device has metadata and
hotplug is enabled, auto-incorporate the device.

Can we assume for all external metadata that spares added any container can be potentially moved between all container the same metadata?

Yes, that can be the default action, and the spare-group keyword can
be specified to override.

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