On Tuesday June 13, [EMAIL PROTECTED] wrote:
>
> On Tue, 13 Jun 2000, Neil Brown wrote:
>
> no, (and i told you this before) it does not need MSDOS style partition
> tables. Linux's partition system is 'generic', and when i implemented this
> i only added the 'lowlevel glue' to support MSDOS-style partitions (that
> was what i can test). It's trivial to add code for every other
> partitioning type as well, such as BSD disklabels, which are available on
> every platform.
>
> (two minutes later) In fact i've just added BSD-disklabels autostart
> support to my tree, it's a twoliner:
>
> --- msdos.c.orig Mon Jun 12 03:27:25 2000
> +++ msdos.c Tue Jun 13 00:46:42 2000
> @@ -256,6 +256,8 @@
> } /* if the bsd partition is not currently known to linux, we end
> * up here
> */
> + if (bsd_p->p_fstype == LINUX_RAID_PARTITION)
> + md_autodetect_dev(MKDEV(hd->major, current_minor));
> add_gd_partition(hd, current_minor, bsd_p->p_offset, bsd_p->p_size);
> current_minor++;
> }
As I said: "and probably all of the short comings can be addressed".
>
> this is the major reason why i consider MD_BOOT an inferior solution, and
> i'm still convinced about phasing it out (gradually, later on). We do not
> need two ways of boot-time starting up arrays, and superblock-less arrays
> are dangerous anyway. Especially as MD_BOOT is fundamentally inferior.
>
> > The other way is to explicitly tell the kernel via md= options. This
> [...]
> > doesn't easily deal with devices changing name (as scsi devices can do
> > when you plug in new devices).
>
> it also doesnt deal with disk failures. Autostart is able to start up a
> (failure-resistent such as RAID1/RAID5) array even if one of the disks has
> failed. MD_BOOT cannot deal with certain types of disk failures.
>
> > So both have short comings, [...]
>
> no, only MD_BOOT has shortcomings, and i'm very convinced it will be
> phased out. The only reason i accepted it is that some people want to
> start up (legacy) non-persistent arrays at boot-time. I'm going to remove
> the ability to start up persistent arrays via MD_BOOT, so that people do
> not get the habit if starting up persistent arrays in an inferior way with
> MD_BOOT. It's a pure compatibility thing, the MD_BOOT code is short and
> localized.
Then I'll have to put it back in.
>
> > be addressed, and probably will over the months, but in any case, it's
> > nice to have a choice (unless it is confusing I guess).
>
> MD_BOOT cannot be fixed. It will _not_ be able to start up arrays if the
> device name changes (eg. due to a failure), no matter how hard you try.
> And yes, MD_BOOT is confusing.
The subject of the sentence to which the "it" refered, was "choice",
not "MD_BOOT".
>
> > Me: I choose MD_BOOT because I like explicit control.
>
> Persistent arrays are _not_ identified by their (temporary) device names.
> Anything short of autostart arrays does not make full use of Linux-RAID's
> capabilities to deal with various failure scenarios, and is fundamentally
> flawed. (if you want to have an explicit pre-rootmount startup method then
> you can still use initrd.)
>
> Ingo
Indeed, initrd is the way I would like to go, but it probably needs to
be made or simple/turn-key first.
Until then, device names can work for finding the parts of RAID just a
well as they can work for finding a root filesystem.
I don't insist you use my prefered method, why do you insist
that I use yours?
NeilBrown
