Re: md extension to support booting from raid whole disks.

[Neil Brown <neilb@suse.de>]

On Wednesday May 13, daniel@centurion.net.nz wrote:
> On Tue, 2009-05-12 at 15:39 +1000, Neil Brown wrote:
> > On Saturday May 9, goswin-v-b@web.de wrote:
> > > "NeilBrown" <neilb@suse.de> 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