On Tue, 13 Jun 2000, Neil Brown wrote:
> One way is by setting the partition type of the relevant partitions.
> This is nice and easy, but requires you to use MSDOS style partition
> tables (which only 99.4% of Linux users do:-), and works fine for
> RAID0 or 1 or 5 or Linear.
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++;
}
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.
> 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.
> 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
