On Tue, 6 Jul 2010 15:03:07 +0100 "Labun, Marcin" <Marcin.Labun@xxxxxxxxx> wrote: > > > -----Original Message----- > > From: Neil Brown [mailto:neilb@xxxxxxx] > > Sent: Thursday, July 01, 2010 8:50 AM > > To: Williams, Dan J; Doug Ledford > > Cc: Labun, Marcin; Czarnowska, Anna; Hawrylewicz Czarnowski, > > Przemyslaw; Ciechanowski, Ed; Healey, Douglas D; Neubauer, Wojciech; > > linux-raid@xxxxxxxxxxxxxxx > > Subject: A policy frame work for mdadm (incorporating domains and > > hotplug and such) > > [cut] > > > > > > Point 2 is that policy revolves primarily around devices (rather than > > arrays) and to a lesser extent around metadata types. > > It is devices that are migrated, devices that arrays are built from, > > devices > > that are automatically made into spares etc. > > Metadata types often encode some specific policy in the metadata, so > > they > > need some fairly strong role in the policy framework too. Often the > > metadata type is like a parameter to a policy. "You can incorporate > > this > > device in any imsm array". > > > > So Abstraction 1 is a "Policy statement". > > > > A policy statement applies to a particular device, possibly in the > > context > > of a particular metadata, and asserts that a particular name has a > > particular value. > > action=spare (ddf1) > > might be a policy statement about a device. It says that where ddf1 > > metadata is involved, the device can be made a hot-spare when it is > > hot-plugged. > > auto=homehost (0.90) > > might be another which says that auto-assembly may use a non- > > disambiguated > > name (no trailing _NN) when assembling this device into a > > metadata=0.90 > > array providing the homehost information in the metadata matches this > > host. > > > > A statement might not have any metadata type associated. > > action=ignore > > applies irrespective of metadata type. > > > > The policy names that I currently envisage are: > > > > action= ignore, include, spare, force-spare > > > > which covers the hotplug actions that --incremental might perform. > > > > auto= yes, homehost, no > > > > which covers the functionality currently in the AUTO mdadm.conf > > line > > > > domain= arbitrary-string > > > > This provides the 'domain' isolation functionality. > > The semantics I have in mind (and the precise details here are > > fairly > > important so this cannot be changed lightly) are: > > A device can have a number of domains, possibly from various > > sources. > > An array can have a number of domains, from the devices plus > > from > > spare-group > > > > A device may be attached to an array if all of the domains of the > > device > > are also domains of the array. The array may have extra domains. > > The > > device may not. > > > > This requires that if there are overlapping domains, they must > > properly > > nest. i.e. the intersection of two domains must be empty, or one > > of the > > domains. It might make sense to have a domain 'global' which all > > devices have, and some other domains which just subsets have. > > > > What is the usage of domain name? They determine whether a device may be attached to an array. Both the device and the array have domain names. A device may only be attached to an array if all of the domain names it has also belong to the array. The exact mechanism for assigning domain names to arrays is not finalised, but the first-estimate is that it is the union of the domain names of all current members. > I understand that each policy line can have a domain token. "can" yes. However some policy lines may not. > In this case each device that matches "match" keyword gains another domain. > But how it can use it? The domains will typically be subset one of another. We might have three sets of devices. All are given domain=global First set is given domain=first second set is given domain=second Then we create two arrays, one from devices in the first set, one from devices in the second set. Now any spare in the first set can be use in the first array Any spare in the second set can be used in the second array Any spare in the third set can be used in any array. > > If each policy line has its own domain, so we have explicit relation > one-to-one between POLICY line and domain name. No, each policy line does not its own domain. Some do, some don't. > Can different POLICY line share the same domain name? Definitely. > > Another questions is domain intersection. > It seems to me that the plan is test if "matching" keyword intersect. I don't currently foresee any explicit testing for intersection. Certainly some devices will match several policy lines, and those policy lines might make related statements - e.g. that might both give different domains to the device, or they might even give the same domain to a device. In generally policy can accumulate. As mentioned above having multiple domains associated with a device is perfectly fine. I'm not sure yet how "action=" policies would accumulate. I suspect that the most permissive would apply, but I'm not satisfied that I have explored all the possibilities yet so I'm not sure. > In case domain would have non-empty intersection if the path globs overlap? Yes, domains can have non-empty intersections. This will normally mean that one is a subset of another, though that isn't strictly necessary. > What else? Type (disk, partition) Metadata name? Sorry, I don't know what you are asking here. > > > Matching multiple policy lines that define conflicting policy names assignment is invalid configuration, right? > (for instance one policy defines action=ignore and the other include and disk matches both POLICY line) > How to deal with it? Good question. I'm beginning to think that "action=ignore" isn't something we really want. It seems appropriate at first glance, but it is inconsistent with the other possible actions as it forbids rather than allows. So we might just discard 'action=ignore'. If we don't want to consider certain devices for md at all, then tell udev not to run mdadm -I on them. That leave action=include # include this in the array if it appears to be a current # member action=re-add # include this in the array if it appears to be a current # member or a member that was recently removed action=spare # include this if either of the above apply, or if it is # a bare device, make it a spare action=force-space# as above, but if that doesn't succeed, make is a spare # anyway Then if multiple action policies apply to the same device, we simply take the most permissive - the last one in the above list. I'm actually wondering if these 'action's should apply during --assemble as well. Normally Assemble will only include devices that are current members. Anything that is a bit old is rejected (by the kernel). i.e. action=include. Probably if action=re-add were in-force, then those rejected devices should be immediately re-added. Can that be extended to other devices? If there are other devices which don't have a domain conflict and which are bare and have action=spare, should they be immediately added as spare devices? I'm not at all sure about force-space though... it seems just too easy for it to destroy data. Thanks, NeilBrown -- 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
