Skip to contentSkip to conversation

understanding mdraid initialization logic

DISCUSSION Gerd v. Egidy 2 participants 3 messages Feb 15, 2011 2 messages not in the archive

lore
Share & tools
lore
#0 lore raw

Hi,

I'm trying to understand what goals dracut wants to reach regarding mdraids - what should the status of the mdraids be when dracut is finished?

Currently I see that when dracut includes an mdadm.conf, all these mds will stay active when dracut ends. When dracut does not use/include an mdadm.conf, the mds will be deactivated again at the end of dracut unless they are needed for the root filesystem.

This logic is in modules.d/90mdraid/parse-md.sh, it is done by conditionally deleting the mdraid-cleanup.sh.

What is the reason for deactivating the mds? Why is this handled differently when an mdadm.conf is present?

I need an dracut image which is portable across a lot of machines so I can't include an mdadm.conf. But when the real system starts after dracut is done, all mds except the root one are gone and can't be mounted through fstab. I use filesystem labels in fstab, so the md numbers are irrelevant.

Kind regards,

Gerd

Signature · 2 lines
Address (better: trap) for people I really don't want to get mail from:
jonas-K4Lox0BdAqn6SQ/niu2adgC/[email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

Trying to guess ...

Quoted 10 lines · Gerd v. Egidy

Hi,

I'm trying to understand what goals dracut wants to reach regarding mdraids - what should the status of the mdraids be when dracut is finished?

Currently I see that when dracut includes an mdadm.conf, all these mds will stay active when dracut ends. When dracut does not use/include an mdadm.conf, the mds will be deactivated again at the end of dracut unless they are needed for the root filesystem.

Quoted 6 lines

This logic is in modules.d/90mdraid/parse-md.sh, it is done by conditionally deleting the mdraid-cleanup.sh.

What is the reason for deactivating the mds? Why is this handled differently when an mdadm.conf is present?

mdadm.conf is present only if you build initrd in hostonly mode - i.e. when you include only modules that are needed for currently running hardware. In this case it can be assumed that all arrays are actually present and used by currently booting system.

If mdadm.conf is not present, it is generic image. In this case you can't be sure that all arrays actually belong to and will be activated by booting system. So they are stopped to avoid confusion.

Quoted 5 lines

I need an dracut image which is portable across a lot of machines so I can't include an mdadm.conf. But when the real system starts after dracut is done, all mds except the root one are gone and can't be mounted through fstab. I use filesystem labels in fstab, so the md numbers are irrelevant.

Well, usually system is expected to boot without initrd as well, so it should be capable of activating those resources itself. I wonder what distro are you using?

A message that is not in the archive (sent off-list or not yet received): AANLkTinpHgBb3EJaXxj+-tznm9S=6asfTmePgDF-c8DL-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#4 lore raw

Hi Andrey,

Quoted 6 lines
Quoted 2 lines

What is the reason for deactivating the mds? Why is this handled differently when an mdadm.conf is present?

If mdadm.conf is not present, it is generic image. In this case you can't be sure that all arrays actually belong to and will be activated by booting system. So they are stopped to avoid confusion.

Belong to what? The linux instance currently running on this system?

I don't see any more harm in keeping active mdraids of other linux instances than activating them for a short time during boot.

Quoted 7 lines
Quoted 5 lines

I need an dracut image which is portable across a lot of machines so I can't include an mdadm.conf. But when the real system starts after dracut is done, all mds except the root one are gone and can't be mounted through fstab. I use filesystem labels in fstab, so the md numbers are irrelevant.

Well, usually system is expected to boot without initrd as well,

I'd say today you usually don't have the kernel modules needed to mount the root statically built in your kernel. So a system won't boot without initrd.

Quoted 3 lines

so it
should be capable of activating those resources itself. I wonder what distro are you using?

I'm using Fedora. But I use rd_NO_MDADMCONF to make sure that the dracut image can be used on multiple systems.

Usually the Fedora dracut includes mdadm.conf and so it does not need to initialize other mds.

Kind regards,

Gerd

Signature · 2 lines
Address (better: trap) for people I really don't want to get mail from:
jonas-K4Lox0BdAqn6SQ/niu2adgC/[email protected]