Patch to add RAID autostart to IBM partitions

Patch to add RAID autostart to IBM partitions

[Pete Zaitcev]

Hi, guys:

This is an implementation of essentially the same mechanism which exists
in msdos.c and sun.c. It is needed when initrd tries to mount a root
on a RAID. One might ask, why the heck initrd cannot do it without a
kernel help. The answer is in the contrived API of the MD driver: there
is no way to ask "assemble md0"; applications must list components.
Anyway, if msdos.c does it, surely ibm.c ought to do it as well.

Please apply.

-- Pete

P.S. Martin: this is for bug LTC10616.

diff -urp -X dontdiff linux-2.6.9-rc4-mm1/fs/partitions/ibm.c linux-2.6.9-rc4-mm1-autoraid/fs/partitions/ibm.c
--- linux-2.6.9-rc4-mm1/fs/partitions/ibm.c	2003-10-01 15:18:05.000000000 -0700
+++ linux-2.6.9-rc4-mm1-autoraid/fs/partitions/ibm.c	2004-10-15 22:38:12.712453680 -0700
@@ -129,6 +129,7 @@ ibm_partition(struct parsed_partitions *
 		while ((data = read_dev_sector(bdev, blk*(blocksize/512),
 					       &sect)) != NULL) {
 			format1_label_t f1;
+			char *ch;
 
 			memcpy(&f1, data, sizeof(format1_label_t));
 			put_dev_sector(sect);
@@ -154,6 +155,14 @@ ibm_partition(struct parsed_partitions *
 			put_partition(state, counter + 1, 
 					 offset * (blocksize >> 9),
 					 size * (blocksize >> 9));
+
+			/* Corrupting the label buffer now to save the stack. */
+			EBCASC(f1.DS1DSNAM, 44);
+			f1.DS1DSNAM[44] = 0;
+			ch = strstr(f1.DS1DSNAM, "PART");
+			if (ch != NULL && strncmp(ch + 9, "RAID  ", 6) == 0)
+				state->parts[counter + 1].flags = 1;
+
 			counter++;
 			blk++;
 		}

Re: Patch to add RAID autostart to IBM partitions

[Christoph Hellwig]

On Fri, Oct 15, 2004 at 10:48:22PM -0700, Pete Zaitcev wrote:
> Hi, guys:
> 
> This is an implementation of essentially the same mechanism which exists
> in msdos.c and sun.c. It is needed when initrd tries to mount a root
> on a RAID. One might ask, why the heck initrd cannot do it without a
> kernel help. The answer is in the contrived API of the MD driver: there
> is no way to ask "assemble md0"; applications must list components.
> Anyway, if msdos.c does it, surely ibm.c ought to do it as well.

We had this for a few partition types (and full block devices) already
and it's been vetoed.  Use mdadm from initrd/initramfs instead.

Re: Patch to add RAID autostart to IBM partitions

[Pete Zaitcev]

On Sat, 16 Oct 2004 12:09:39 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> We had this for a few partition types (and full block devices) already
> and it's been vetoed.  Use mdadm from initrd/initramfs instead.

It is doable in theory, but in practice mdadm is too retarded (I'm taliking
about mdadm 1.6.0 here). Its man page says:

    mdadm can perform (almost) all of its functions  without  having  a
    configuration  file  and  does  not use one by default.

I guess "almost" is the key. Firstly, it collapses with any attempt to run
"mdadm -A -s" or any variation of such, because it's full of places like
this.

	mddev_ident_t array_ident = conf_get_ident(configfile, dv->devname);
	mdfd = open_mddev(dv->devname, array_ident->autof);

Obviously, array_ident is NULL if a config file is not present. It is
possible to fool the stupid thing by giving it a dummy config file,
like this one:

DEVICE partitions
ARRAY /dev/md0

It still won't scan, aborting with this:
mdadm: /dev/dasda has no superblock - assembly aborted

The ChangeLog looks as if someone tried to make it work, but I observe
it didn't go very far.

-- Pete

Re: Patch to add RAID autostart to IBM partitions

[Neil Brown]

On Saturday October 16, zaitcev@redhat.com wrote:
> On Sat, 16 Oct 2004 12:09:39 +0100
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > We had this for a few partition types (and full block devices) already
> > and it's been vetoed.  Use mdadm from initrd/initramfs instead.
> 
> It is doable in theory, but in practice mdadm is too retarded (I'm taliking
You sweet-talker you....

> about mdadm 1.6.0 here). Its man page says:
> 
>     mdadm can perform (almost) all of its functions  without  having  a
>     configuration  file  and  does  not use one by default.
> 
> I guess "almost" is the key. Firstly, it collapses with any attempt to run
> "mdadm -A -s" or any variation of such, because it's full of places like
> this.
> 
> 	mddev_ident_t array_ident = conf_get_ident(configfile, dv->devname);
> 	mdfd = open_mddev(dv->devname, array_ident->autof);

Hmm, thanks for the bug report.  I'll fix that rather silly bit of
code..... there.  The next release won't have that bug.
> 
> Obviously, array_ident is NULL if a config file is not present. It is
> possible to fool the stupid thing by giving it a dummy config file,

There's that silver tongue again.  It makes one feel all warm
inside....

> like this one:
> 
> DEVICE partitions
> ARRAY /dev/md0
> 
> It still won't scan, aborting with this:
> mdadm: /dev/dasda has no superblock - assembly aborted

Yes, you haven't told it what defines "/dev/md0", so it assumes the
first device listed will define it, but /dev/dasda doesn't so....

You have to tell mdadm how to recognise /dev/md0.  Possibly by UUID.
Possibly by "minor number".
e.g.

 DEVICE partitions
 ARRAY /dev/md0 super-minor=0

which means "if you find any devices listed in /proc/partitions which
contains an MD superblock which has a "md_minor" field of "0", then
use those to assemble /dev/md0.

This will often be what you want, but might not always.  e.g. if you
have plugged in a drive that was part of /dev/md0 in another machine,
then mdadm will have no way of knowing which drive is the "right" one.

NeilBrown

Re: Patch to add RAID autostart to IBM partitions

[Pete Zaitcev]

On Tue, 19 Oct 2004 11:54:14 +1000, Neil Brown <neilb@cse.unsw.edu.au> wrote:

Dear Neil,

thank you for your patient reply. It makes things a lot clearer.

> Yes, you haven't told it what defines "/dev/md0", so it assumes the
> first device listed will define it, but /dev/dasda doesn't so....

> You have to tell mdadm how to recognise /dev/md0.  Possibly by UUID.
> Possibly by "minor number".
> e.g.
> 
>  DEVICE partitions
>  ARRAY /dev/md0 super-minor=0
> 
> which means "if you find any devices listed in /proc/partitions which
> contains an MD superblock which has a "md_minor" field of "0", then
> use those to assemble /dev/md0.

I see now. I'm sorry that I was unable to deduce it from the manual.
One last question, if the -As worked, would it do the same?

> This will often be what you want, but might not always.  e.g. if you
> have plugged in a drive that was part of /dev/md0 in another machine,
> then mdadm will have no way of knowing which drive is the "right" one.

I guess there's nothing we can do about possible conflicts, except warn
the operator at installation time. What is the recommended way to ask
mdadm to list all conflicts, or simply all found array devices, for the
benefit of an installation program reading a pipe?

-- Pete

Re: Patch to add RAID autostart to IBM partitions

[Neil Brown]

On Tuesday October 19, zaitcev@redhat.com wrote:
> On Tue, 19 Oct 2004 11:54:14 +1000, Neil Brown <neilb@cse.unsw.edu.au> wrote:
> 
> Dear Neil,
> 
> thank you for your patient reply. It makes things a lot clearer.
> 
> > Yes, you haven't told it what defines "/dev/md0", so it assumes the
> > first device listed will define it, but /dev/dasda doesn't so....
> 
> > You have to tell mdadm how to recognise /dev/md0.  Possibly by UUID.
> > Possibly by "minor number".
> > e.g.
> > 
> >  DEVICE partitions
> >  ARRAY /dev/md0 super-minor=0
> > 
> > which means "if you find any devices listed in /proc/partitions which
> > contains an MD superblock which has a "md_minor" field of "0", then
> > use those to assemble /dev/md0.
> 
> I see now. I'm sorry that I was unable to deduce it from the manual.
> One last question, if the -As worked, would it do the same?

No.  -As needs a config file.  Currently without the config file, it
crashes.  In the next release, without a config file it will fail more
gracefully. 

> 
> > This will often be what you want, but might not always.  e.g. if you
> > have plugged in a drive that was part of /dev/md0 in another machine,
> > then mdadm will have no way of knowing which drive is the "right" one.
> 
> I guess there's nothing we can do about possible conflicts, except warn
> the operator at installation time. What is the recommended way to ask
> mdadm to list all conflicts, or simply all found array devices, for the
> benefit of an installation program reading a pipe?

These isn't really one.
  mdadm -Es -c partitions

will list all possibly arrays - you could then pick the one you want.

But choosing the drives to assemble to make an md array is a lot like
choosing the partition to mount to find the root filesystem.  It might
be possible to guess, but if you rely in the guess, it will sometimes
be wrong.  At install time, it is safe to guess if there is only one
candidate.  If there are more, you really have to ask.

After that, the boot process (or whatever process assembles the
arrays) really needs to have been told how to recognise components,
just like lilo tells linux which device has root (root=).

The output of mdadm -E could possibly be made more friendly (currently
it will happily list arrays that cannot possibly be completely
assembled right along side arrays that are likely to work).

NeilBrown