understanding mdraid initialization logic

understanding mdraid initialization logic

[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.

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

-- 
Address (better: trap) for people I really don't want to get mail from:
jonas-K4Lox0BdAqn6SQ/niu2adgC/G2K4zDHf@public.gmane.org

Re: understanding mdraid initialization logic

[Andrey Borzenkov]

Trying to guess ...

On Tue, Feb 15, 2011 at 2:43 PM, Gerd v. Egidy <lists-6VzpN07DMvo@public.gmane.org> wrote:
> 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?
>

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.

> 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?

Re: understanding mdraid initialization logic

[Gerd v. Egidy]

Hi Andrey,

> > 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.

> > 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.

> 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

-- 
Address (better: trap) for people I really don't want to get mail from:
jonas-K4Lox0BdAqn6SQ/niu2adgC/G2K4zDHf@public.gmane.org