Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: 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. How often does this happen, and how grave/dangerous are the effects? a/ no idea. b/ it all depends... It is the sort of thing that happens when something has just gone drastically wrong and you need to stitch things back together again as quickly as you can. You aren't exactly panicing, but you are probably hasty and don't want anything else to go wrong. If the array from the 'other' machine with the same name has very different content, then things could go wrong in various different ways if we depended on that name. It is true that the admin would have to by physically present and could presumably get a console and 'fix' things. But it would be best if they didn't have too. They may not even know clearly what to do to 'fix' things - because it always worked perfectly before, but this time when in a particular hurry, something strange goes wrongs. I've been there, I don't want to inflict it on others. 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. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? No. We cannot assume that an average sys-admin will have a deep knowledge of md and mdadm. Many do, many don't. But in either case the behaviour must be predictable. After all, Debian is for when you have better things to do than fixing systems Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? What exactly are you unconvinced of? I agree completely that mounting filesystems by UUID is the right way to go. (I also happen to think that assembly md arrays by UUID is the right way to go too, but while people seem happy to put fs uuids in /etc/fstab, they seem less happy to put md uuids in /etc/mdadm.conf). As you say in another email: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 NeilBrown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Tue, Feb 23, 2010 at 4:10 PM, Neil Brown ne...@suse.de wrote: On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: 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. How often does this happen, and how grave/dangerous are the effects? a/ no idea. b/ it all depends... It is the sort of thing that happens when something has just gone drastically wrong and you need to stitch things back together again as quickly as you can. You aren't exactly panicing, but you are probably hasty and don't want anything else to go wrong. If the array from the 'other' machine with the same name has very different content, then things could go wrong in various different ways if we depended on that name. It is true that the admin would have to by physically present and could presumably get a console and 'fix' things. But it would be best if they didn't have too. They may not even know clearly what to do to 'fix' things - because it always worked perfectly before, but this time when in a particular hurry, something strange goes wrongs. I've been there, I don't want to inflict it on others. 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. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? No. We cannot assume that an average sys-admin will have a deep knowledge of md and mdadm. Many do, many don't. But in either case the behaviour must be predictable. After all, Debian is for when you have better things to do than fixing systems Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? What exactly are you unconvinced of? I agree completely that mounting filesystems by UUID is the right way to go. (I also happen to think that assembly md arrays by UUID is the right way to go too, but while people seem happy to put fs uuids in /etc/fstab, they seem less happy to put md uuids in /etc/mdadm.conf). As you say in another email: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 NeilBrown -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Would a permissible behavior be to add a third case: If an entry is not detected in the mdadm.conf file AND the homehost is not found to match ask on the standard console what to do with something like a 30 second timeout; as well as being noisy in the kernel log so the admin knows why it was slow. Really there should probably be two questions: 1) Do you want to run this? 2) What name do you want? (with the defaults being yes, and the currently chosen alternate name pattern). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [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? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
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? I can think of one or two. In the case of network boot, where the kernel and initrd served up via tftp, but the required filesystems are per host raid volumes served up ala ATAoverEthernet, iSCSI etc storage network. This could use the boot network device MAC or dhcp assigned hostname to as the homehost search paramater. This would of course require someway to tell mdadm how to obtain this homehost parameter. This could work well where different groups of hosts using different raid volumes for the root (or other) filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to identify that groups homehost search parameter. Another scenario, is a dual boot system that has separate raid volumes for the respective root filesystems, along with a separate initrd image for each OS. A system uuid stored in the initrd would work in this case for the homehost search parameter. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Mon, 22 Feb 2010 10:16:32 +0100 martin f krafft madd...@madduck.net wrote: also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: 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. How often does this happen, and how grave/dangerous are the effects? 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. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? -- martin | http://madduck.net/ | http://two.sentenc.es/ Escape Meta Alt Control Shift spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
