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. -- 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
