On Wednesday May 13, daniel@xxxxxxxxxxxxxxxx wrote: > On Tue, 2009-05-12 at 15:39 +1000, Neil Brown wrote: > > On Saturday May 9, goswin-v-b@xxxxxx wrote: > > > "NeilBrown" <neilb@xxxxxxx> writes: > > > > > > > On Sat, May 9, 2009 7:50 am, Goswin von Brederlow wrote: > > > > > > > >>>> So I still plan to offer a "--reserve-space=2M" option for mdadm to > > > >>>> allow the first 2M of each device to not used for raid data. Whether > > > >>>> any particular usage of this option is viable or not, is a different > > > >>>> question altogether. > > > >> > > > >> How exactly would that layout be then? > > > >> > > > >> Block 0 bootblock > > > >> Block 1 raid metadata > > > >> Block x 2M reserved space > > > >> Block x+2M start of raid data > > > >> > > > >> Like this? > > > > > > > > When using 1.2 metadata, yes, possible with bitmap > > > > inserted between the reserved space and the start of raid data. > > > > > > That realy seems to be the best option. Simple to implement, simple to > > > use and if mdadm copies the reserved space from old to new drives when > > > adding one it gives us exactly what we want. > > > > > > Are you working on that already or do you think it needs more discussion? > > > > Discussion is good.... > > > > I have just pushed out some changes to the 'master' branch of > > git://neil.brown.name/mdadm > > > > The last patch adds "--reserve-space=" support to create. > > It only works with 1.x metadata (and causes the default to be 1.0). > > > > You cannot hot-add a bitmap to a 1.1 or 1.2 array created with this > > feature (the kernel cannot be told the right thing to do yet). > > > > The space can have a K, M, or G suffix with the obvious meanings. > > K is the default. > > > > mdadm currently does not copy any data from one device to another. > > This could possibly be added for "--add" but not for "--create". > > 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. Having a replicated boot loader and having a raid1 are conceptually quite different things. A raid1 says "keep N (typically 2) copies of the data somewhere for me". A replicated boot loader says "store this boot loader on every bootable device". One is more abstract, the other is more concrete. Maybe it is a very subtle distinction, but I think it is worth maintaining. Get your boot-loader-installer to install at the front of every drive - don't bother having a raid1 there that is never read and hardly ever written.. 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
