On Apr 20, 2009, at 2:08 AM, Neil Brown wrote:
On Saturday April 18, dledford@xxxxxxxxxx wrote:I've been thinking about this, and this is the method I would suggest.Add two new keywords to the mdadm.conf file: ASSEMBLE INCREMENTAL Allow each of those keywords to have one of three set values: None - Don't attempt to assemble any arrays regardless of whether or not they are in the mdadm.conf file or not Known - Only assemble arrays with a matching array line All - Attempt to assemble any array found The combination of the two options and the three settings would allow you to control mdadm behavior for both array assembly modes independently. That, combined with my previous patch, should allow arrays to assemble well, with known names, allow you to control auto assembly by udev, and in the event that your machine just exports volumes to other machines for their use, stop assembly entirely.Why "None"?? Why would you use "None" rather than "Known" with an empty list of arrays?
For the same reason we have a write-mostly flag for raid1. Maybe we have two machines that both want/need to know about a given array, but only one should access it at a time (clustered failover scenario). On the non-primary node, you use None, on the primary you use Known, and bootup proceeds properly. Then on failover, on the non-primary machine you already have the array in mdadm.conf and can bring it up safely and reliably in manual operation. This requires that mdadm tell the difference between manual and automatic mode (aka, from a command line instead of a shell script), so you need a new option flag to override the assembly/incremental settings, but that's the only change necessary.
Why have two options: ASSEMBLE and INCREMENTAL ?? If what circumstance would you use different settings for these two options.
I can't speak to other distros, but at least Fedora still does assembly on bootup, and incremental after bootup (well, we switch to incremental part way through bootup, mainly once rc.sysinit has completed). Maybe you have a machine that exports raid block devices via AOE, and these are always present at bootup, so you want ASSEMBLY to none. Yet, you also plug in a roving USB disk array for online backups, so you want that to come up via hot plug. There are lots of reasons things might be done. I just suggested a method that is flexible enough to satisfy even the most whacked out scenario.
I current have two patches sitting in my scratch queue. I am by no means committed to them. One allows you to have e.g. ARRAY ignore UUID=foo:bar:dead:beef with the meaning that auto-assembly will ignore that array. If you run mdadm --assemble /dev/md/thing --uuid foo:bar:dead:beef it will still assemble the array, but any auto-assembly will ignore it. The other allows you to say: AUTO -ddf -0.90 +all which means don't auto-assemble any 'ddf' or '0.90' array, but do auto-assemble anything else that is recognised. You might want to use dmraid for ddf?? If you just have AUTO -all then it won't auto-assemble anything, which is much like your ASSEMBLE Known INCREMENTAL Known NeilBrown --To unsubscribe from this list: send the line "unsubscribe linux- raid" inthe body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband
Attachment:
PGP.sig
Description: This is a digitally signed message part
