Hi,
As you probably know I'm working on making Fedora 12 use mdraid
instead of dmraid for Intel BIOS-RAID setups.
The installer (anaconda) part is mostly done (needs more testing)
and now I'm looking at implementing support for this in dracut
(the new mkinitrd for Fedora 12).
So I've been testing how this works for both imsm mdraid sets
and native mdraid metadata sets, in both cases using a 2 disk
mirror, so that the set can also be brought up in degraded mode.
Currently the udev rules use incremental assembly like this:
mdadm -I /dev/mdraid-member
There are 2 problems with this:
1) When doing this for native mdraid metadata arrays, if only
one disk is present the set never gets activated
2) When doing this for imsm metadata arrays, as soon as the
first disk is incrementally added, the set gets activated
in degraded mode and stays that way, the second disk
will get added to the container, but not to the actual
sets in the container
And these 2 problems have 2 different solutions:
1) An incomplete, but potentially activatable in degraded mode
set can be activated using mdadm --run /dev/md#
2) One can stop this problem by using:
mdadm -I --no-degraded /dev/mdraid-member
instead (this does not change anything for
native mdraid metadata format sets)
But if that is done, the sets in the container never get
activated, this can be fixed by running
mdadm -I /dev/md# on the container device
So my proposed solution for this is when udev is done scanning
(when the event queue is empty, detected using the same mechanism as
dracut is using for dmraid), do the following:
For each /dev/md#
run mdadm --export --detail, and get the MD_LEVEL
if MD_LEVEL == "container":
mdadm -I /dev/md#
else
mdadm --run /dev/md#
This will:
1) Bring up raid sets inside containers (such as imsm raidsets)
2) Bring up incomplete raid sets in degraded mode where possible
I'll post a patch implementing this later today.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
