> > Could we do this better using containers and snia's ddf in intels matrix > > (or our own) metadata to define the data areas and this way create a > > raid1 container at the start of the disks and use 1.0 format superblock > > and metadata at the end of the drive (as long as this doesn't mess with > > the metadata. > > > > This would solve the syncing of boot sectors because it would be done as > > part of normal raid 1. Hot add would simply be a matter of adding > > members to the container. The only issue I can see is whether you are > > able to hot resize the data areas in containers as part of the grow > > feature, or would we have to do a metadata tweak to redefine the size of > > data areas. > > While it might be possible to do something vaguely like this, I don't > want to. > Is it already possible to do with mdadm v3? BTW, I'm not talking about just raiding the boot sector, but a raid1 volume with a filesystem for /boot with the embedded bootsector at the start of it. This means that for every member disk that includes the /boot volume we have a mirror. The description I got about ddf|matrix containers led me to believe this was a robust way to do this. What's the point in supporting ddf|matrix containers if we can't create the data areas within them to suit particular use cases like this? If we could/can then nothing further needs to be done to md/mdadm to allow me to implement my preferred boot solution. > don't bother having a raid1 there that is never read > and hardly ever written.. ???? It's read every time we boot! I guess I've failed to communicate what I'm after effectively! :( -- Daniel Reurich Centurion Computer Technology (2005) Ltd Ph 021 797 722 -- 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
