On Mon, Mar 29, 2010 at 11:10 AM, Doug Ledford <dledford@xxxxxxxxxx> wrote: > The second thing I'm having a hard time with is the spare-group. To be > honest, if I follow what I think I should, and make it a hard > requirement that any action other than none and incremental must use a > non-global path glob (aka, path= MUST be present and can not be *), then > spare-group looses all meaning. I say this because if a disk matches > the path glob is it in a specific spare group already (the one that this > DOMAIN represents) and ditto if arrays are on disks in this DOMAIN, then > they are automatically part of the same spare-group. In other words, I > think spare-group becomes entirely redundant once we have a DOMAIN keyword. I agree once you have a DOMAIN you implicitly have a spare-group. So DOMAIN would supersede the existing spare-group identifier in the ARRAY line and cause mdadm --monitor to auto-migrate spares between 0.90 and 1.x metadata arrays in the same DOMAIN. For the imsm case the expectation is that spares migrate between containers regardless of the DOMAIN line as that is what the implementation expects. However this is where we get into questions of DOMAIN conflicting with 'platform' expectations, under what conditions, if any, should DOMAIN be allowed to conflict/override the platform constraint? Currently there is an environment variable IMSM_NO_PLATFORM, do we also need a configuration op > I'm also having a hard time justifying the existence of the metadata > keyword. The reason is that the metadata is already determined for us > by the path glob. Specifically, if we assume that an array's members > can not cross domain boundaries (a reasonable requirement in my opinion, > we can't make an array where we can guarantee to the user that hot > plugging a replacement disk will do what they expect if some of the > array's members are inside the domain and some are outside the domain), > then we should only ever need the metadata keyword if we are mixing > metadata types within this domain. Well, we can always narrow down the > domain if we are doing something like the first three sata disks on an > Intel Matrix RAID controller as imsm and the last three as jbod with > version 1.x metadata by putting the first half in one domain and the > second half in another. And this would be the right thing to do versus > trying to cover both in one domain. That means that only if we ever > mixed imsm/ddf and md native raid types on a single disk would we be > unable to narrow down the domain properly, and I'm not sure we care to > support this. So, that leaves us back to not really needing the > metadata keyword as the disks present in the path spec glob should be > uniform in the metadata type and we should be able to simply use the > right metadata from that. ...but this assumes we already have an array assembled in the domain before the first hot plug event. The 'metadata' keyword would be helpful at assembly time for ensuring only arrays of a certain type are brought up in the domain. We also need some consideration for reporting and enforcing 'platform' boundaries if the user requests it. By default mdadm will block attempts to create/assemble configurations that the option-rom does not support (i.e. disk attached to third-party controller). For the hotplug case if the DOMAIN is configured incorrectly I can see cases where a user would like to specify "enforce platform constraints even if my domain says otherwise", and the inverse "yes, I know the option-rom does not support this configuration, but I know what I am doing". So I see a couple options: 1/ path=platform: auto-determine/enforce the domain(s) for all platform raid controllers in the system 2/ Allow the user to manually enter a DOMAIN that is compatible but different than the default platform constraints like your 3-ahci ports for imsm-RAID remainder reserved for 1.x arrays example above 3/ Allow the user to turn off platform constraints and define 'exotic' domains (mixed controller configurations). -- 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
