On 29/04/2010 02:19, Dan Williams wrote:
Neil Brown wrote:
I'm not sure how this fits with imposing platform constraints.
As platform constraints are closely tied to metadata types, it might
be OK
to have a metadata-specific tags (imsm=???) and leave to details to the
metadata handler???
Dan: help me understand these platform constraints: what is the most
complex
constraint that you can think of that you might want to impose?
At this point we really only need one constraint: prevent controller
spanning. If for example I take an existing imsm member off of ahci and
reattach it via a usb-to-sata enclosure mdadm needs a policy to prevent
associating that drive with anything on ahci.
In a pinch this policy can be disabled, but you wouldn't want to rebuild
across usb or any other controller because the option-rom only talks
ahci and will mark the drive missing.
So something like DOMAIN spanning=imsm, to tell mdadm to follow imsm
rules for this domain. Where 'spanning' is policy tag??
Why isn't DOMAIN path=pci-0000:00:1f.2-scsi-[012345]* enough? Can't
arrays span multiple Intel/imsm controllers? And if I start off my array
on one Intel/imsm controller, and I add another JBOD controller,
shouldn't I be allowed to grow my array to span the two controllers
without rebuilding the array with new metadata? I know I can't expect
the option ROM to cope with or boot off this array but would the option
ROM in some manner damage such an array?
Cheers,
John.
--
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
