On Thu, Mar 25, 2010 at 8:04 AM, Labun, Marcin <Marcin.Labun@xxxxxxxxx> 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. >> >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
