dracut waiting for background mdadm reconstruction to complete
mrsam at courier-mta.com
Thu Dec 1 22:17:10 UTC 2011
Daniel Drake writes:
> On Wed, Nov 30, 2011 at 5:15 PM, Sam Varshavchik <mrsam at courier-mta.com>
> > Daniel Drake writes:
> >> My understanding is that this reconstruction is a background task, is
> >> there really a need for this to hold up boot?
> >> This behaviour comes from
> >> 0064-90mdraid-wait-for-md-devices-to-become-clean.patch in the
> >> dracut-013-19.fc16 package.
> > What part dracut runs during boot?
> Not sure if I understand the question.
> Dracut runs "mdadm -W" for each mdraid device during every boot when
> the mdraid module is included in the initramfs. This is illustrated
> clearly in the patch in question:
Ok, so it's not dracut itself that runs, it's what it puts into the
initramfs. That's what confused me.
> -W is documented to behave as follows:
> -W, --wait
> For each md device given, wait for any resync, recovery,
> reshape activity to finish before returning. mdadm will
> with success if it actually waited for every device listed,
> erwise it will return failure.
Not sure I understand the need for that at boot, myself.
mdraid does seem to have become a little bit of a fustercluck, recently. I
now know more about raid than I ever wanted to know. And this one should
make installing Fedora on a large mdraid box even more fun. Anaconda will
happily create mdraid partitions for you, if you ask, and then proceed to
install everything; but I'm sure it won't wait for the just-assembled arrays
to sync up, so the first boot after a Fedora install will now halt – likely
with nary a clue what's going on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111201/d14d8419/attachment-0001.bin
More information about the devel