On 2/1/2011 10:22 PM, NeilBrown wrote: > There is a difficulty in case 2 as it is not clear who's responsibility it is > to write a partition table at the start of each device. > Presumably GRUB doesn't like to write partition tables unless one already > exists. Yes, it preserves the existing partition table and just modifies the boot loader code in the MBR. > Currently mdadm doesn't write a partition table either. Possibly it could, > but I would rather avoid that if possible. > Maybe once case 2 has been clearly identified, GRUB could consider that > sufficient permission to write a boot block and partition table even if no > partition table existed?? Possibly, but that is the kind of thing I think should require an explicit request. Whether it is done by mdadm or not, I think that someone should write a protective mbr. Since mdadm is what is effectively formatting the disk, it makes the most sense to me to do it there, rather than in grub, which is just trying to install a boot loader to an existing disk. I suppose the OS installer could add the MBR before asking mdadm to add its superblocks too. What partition type would be appropriate to use? > In the 'reserved' case, mdadm would also report where the space is. e.g. > > MD_BOOT_SPACE="/dev/sda 8192 32768" > > means that from byte offset 8192 there is 32768 bytes of available space. > I would need to make sure that mdadm kept that space available, so I would > need to know how much to reserve. Maybe 32K. Maybe 1M is safe? Sounds good. Grub is used to operating with 32k or less since that is the historical amount of free space following the MBR. > However there is another complication. > I understand that the boot block sometimes lives at the start of the > partition instead of (or as well as) the start of the device. > I'm fairly syslinux does this - I don't know about GRUB. > So I really want to still report BIOS or 'reserved' or 'no' even when > partitions are in use. Grub can be installed to the partition boot block, but it is strongly discouraged since there is no gap to embed the core into, so the boot block must use block lists to locate it. This comes with all kinds of headaches, including not being possible at all on some filesystems, and frequently breaking on others. Either way you still have to have boot code in the MBR to go load the partition boot block, so I don't think that changes anything with respect to this discussion. > So maybe I should scrap case 0 (MD_BOOTABLE=partitions), assume that the > boot-loader configurer can detect and understand partitions itself, and just > report the other 3 cases ignoring the details about partitions. > > Would that be helpful? Would it get used? How could it be better? Yes, it sounds quite helpful. -- 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
