Re: Is mdadm.conf needed?

[Joe Landman <joe.landman@gmail.com>]

On 03/07/2014 03:00 PM, Chris Murphy wrote:
>
> On Mar 6, 2014, at 7:13 PM, Martin T <m4rtntns@gmail.com> wrote:
>
>> Hi,
>>
>> while most of the Linux software-RAID related tutorials suggest to
>> have the mdadm.conf file up to date, then is it actually needed or
>> used any more? I mean all the data needed by kernel for creating
>> the RAID arrays should be stored in the superblocks, shouldn't it?
>> Or in which situation the mdadm.conf is needed?
>
> Good question. mdadm.conf is baked into the initramfs by dracut,
> along with mdadm, on Fedora systems. I haven't tried to willfully
> break it by deleting mdadm.conf and rebuilding the initramfs to see
> if it still works.

On diskless systems, I have as part of the startup, an

	mdadm --examine --scan > /tmp/mdadm.scanned.conf
	mdadm -As --conf=/tmp/mdadm.scanned.conf

so technically its not needed a-priori here.  For systems with the root 
on a particular RAID you would want to assemble the RAID before the 
switch.  Most dracut based systems complain quite vociferously when you 
make mdadm go away, as they don't seem able to do what we've done above 
to figure out what they should assemble.

> I'm pretty sure it happens within the initramfs prior to the kernel
> even attempting to mount root. On systemd systems this could be
> better learned by passing systemd.log_level=debug
> systemd.log_target=console. The initramfs contains systemd, mdadm,
> mdadm.conf - and I'm pretty sure systemd activates that service, and
> then mdadm uses the mdadm.conf that's in the initramfs to assemble
> the array, and then systemd mounts it per the kernel command line
> which specifies root as an mduuid.

It would be nice if, as part of the startup, it did a scan, a comparison 
of the root device to whats available, and instead of timing out or 
panicing (both of which I've seen), that it  drops into a shell if the 
root raid device is either a) not there, or b) not ok to assemble.  The 
rd.shell dracut line sorta/kinda does this.  I am not sure what the 
systemd equivalent is.

Basically what I am saying is that the metadata for assembling the RAIDs 
is on the disks themselves, and the mdadm.conf (if it exists) should be 
used for confirmation/security/warning/error reporting purposes ... and 
not necessarily for actual assembly.