On Mon, 22 Feb 2010 10:16:32 +0100 martin f krafft <madduck@xxxxxxxxxxx> wrote: > also sprach Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> [2010.02.21.2113 +0100]: > > I do not see how the "homehost" plays a role, here. > > Neil, > > Could you please put forth the argument for why the homehost must > match, and why unconditional auto-assembly is not desirable? > Realistically, what problems are we protecting against? > The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. mdadm will currently assembly any array that it finds, but will not give a predictable name to anything that looks like it might be imported from a different host. So if you have 'md0' on each of two computers, one computer dies and you move the devices from that computer to the other, then as long as the bios boots of the right drive, mdadm will assemble the local array as 'md0' and the other array as 'something else'. There are two ways that mdadm determines than array is 'local'. 1/ is the uuid listed against an array in mdadm.conf 2/ is the 'homehost' encoded in the metadata. If either of those is true, the array is local and gets a predictable name. If neither, the name gets an _%d suffix. This is only an issue if you use device name (.e.g /dev/md0 or /dev/md/root) to mount the root filesystem. If you use mount-by-uuid then it clearly doesn't matter what name mdadm assembles the array under. In that case, the fs UUID (stored on the initramfs or similar) will assure the necessary uniqueness and mdadm need not worry about homehost. But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Does that clarify things enough? NeilBrown -- 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
