On 6/30/2010 11:50 PM, Neil Brown wrote:
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.
You lost me here "or one of the domains..." must be a superset of the other?
How do we a priori know which domain an array belongs to? Will we
require them to be tagged (makes our job easier at the cost of some
configuration file maintenance for the administrator). Taking the
domain == controller example, if a user identifies an array as
belonging to controller1 in the configuration file and later moves a set
of member devices to controller2 I assume we ignore those devices right?
This would simplify things for the imsm assembly case because it
requires the array-to-domain association to be identified ahead of time
rather than arbitrarily autodetected by where we happen to find the
first array member.
If an assembly statement is ambiguous we fail and ask for the domain to
be clarified.
There is probably room for other policies like whether to start an
incrementally assembled degraded array early, or wait until it is not
degraded. Maybe some policy of handling "prodigal device" situations where
two halfs of a mirror both this they are "it" and the other is "not".
By now Doug (hope your back is feeling better) will have noticed that
partitions haven't been mentioned yet. So it is time for them.
Point 3: partitions become a new metadata type (or types).
If we want mdadm to ensure there is a MBR partition table on a device, then
provide a policy statement like
action=spare (mbr)
Where the metadata type is determined by the current arrays in the
domain where the device was attached if I am following correctly.
[..]
Point 6: We probably have platform policy too. I'm not really sure what
this will involve, and what if anything needs to be explicit. Maybe just
platform-policy imsm
in mdadm.conf tell mdadm to query the platform and deduce some policy
statements or police rules.
I don't know if we need to add platform policy to the configuration
file, maybe we can revisit this when we have a metadata format where
"RAID mode" cannot be disabled in the firmware. For now the policies
enforced by the platform really are not optional (lest we confuse
firmware), so I'd just as soon not allow them to be configured. The
mitigations are turn off raid mode or set the environment variable which
should tell you that you are doing something tricky. I'll come back if
I think of a non-critical platform dependent policy.
[..]
The part of this that I'm least confident of is assigning domains to arrays.
It would be nice if every array came pre-tagged with what domain it
belongs, but that can't be a requirement. Conversely users that don't
set up a domain will sometimes find one forced upon them by the
metadata. On such a platform where there are hardware defined domains I
think it would be reasonable for the user to identify which domain is
the context for the action.
Like the following, (assuming an empty mdadm.conf) sda has imsm metadata
attached to ahci and sdb has imsm metadata, but is attached to usb.
mdadm -A /dev/md0 /dev/sda /dev/sdb
...we fail with an error message like "/dev/sda was tagged as a member
of the ahci domain while /dev/sdb is only a member of the global domain,
aborting".
mdadm -A /dev/md0 /dev/sda /dev/sdb --domain ahci
...would succeed with a message like "/dev/sdb is not a member of the
ahci domain, ignoring."
Extracting a list of policy statements for each device sounds a bit
cumbersome. Maybe if I cache enough bits of it, it will work nicely.
Comments, as always, are most welcome.
Thanks for the thoughtful write up, as always.
--
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
