The attached patch against 2.4.16 does the following:

Briefly:
a. auto started MD arrays are started in ascending order
b. auto start MD arrays that are mixed physical devices and other MD arrays
c. fsync's MD array after resync is complete.


Rational:
a. I think the characteristics of a system that attempts to guarantee the order
   arrays are initialized, rather than by depending on the physical device (disks
   and partitions) assignment in the system, is preferable.  That is to say, if you
   add new drives and/or partitions and create/change your RAID arrays the order that
   the arrays are started may change.  This is not necessarily a problem for arrays
   that are all true physical devices, i.e.. pure arrays.  Enter "b" kernel auto-start
   of non-pure arrays.
b. Allow the kernel to auto-start RAID arrays that consist of a mix of auto-start
   disk partitions (marked FD) and other running RAID arrays by starting all "pure"
   arrays first than "non-pure" arrays secondly.  As long as an array has at least
   one disk partition mark for auto-start, this patch will allow the kernel to also
   add to that array any MD device that is already running.
c. After RAID 1 resync the system sat for 4 hours on an idle system showing that there
   were a few blocks difference between the size of the array and the blocks that were sync'd.
   A manual "sync" finished the RAID resync.  Why hasn't the system flushed old buffers???

So far I've tested with:

1. md0 being a RAID 0 device consisting of 2 1G drives, and md1 being a RAID 1 device with
   a real 2G drive and md0 as the mirror device.
2. reverse the above... md1 is RAID 0 w/ 2 1G drives, and md0 being the RAID 1 device with
   a real 2G drive and md1 as the mirror device.

The kernel happily starts both arrays either way with this patch...no need for kernel command
line/lilo config options/parameters.

Please CC me.
Martin