Daniel Drake writes:
On Wed, Nov 30, 2011 at 5:15 PM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:> 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.
http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=blob;f=0064-90mdraid- wait-for-md-devices-to-become- clean.patch;h=58c786cc5ca0b94fd138674c54417w29c38befc0;hb=refs/heads/f16-W is documented to behave as follows: -W, --waitFor each md device given, wait for any resync, recovery, or reshape activity to finish before returning. mdadm will return with success if it actually waited for every device listed, oth‐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.
Attachment:
pgpEG_tHF685n.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
