-----Original Message-----
From: Neil Brown [mailto:neilb@suse.de]
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@vger.kernel.org
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? 
I understand that each policy line can have a domain token.
In this case each device that matches "match" keyword gains another domain. 
But how it can use it?

If each policy line has its own domain, so we have explicit relation 
one-to-one between POLICY line and domain name.
Can different POLICY line share the same domain name?

Another questions is domain intersection. 
It seems to me that the plan is test if "matching" keyword intersect. 
In case domain would have non-empty intersection if the path globs overlap? 
What else? Type (disk, partition) Metadata name?


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? 




Thanks,
Marcin Labun