On Wed, Apr 28, 2010 at 7:37 PM, Neil Brown <neilb@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
