FS#20117 - [initscripts] supporting of mdadm

Attached to Project: Arch Linux
Opened by Roman Kosenko (kite) - Thursday, 08 July 2010, 18:37 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 10 April 2011, 02:21 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
I want to have possibility to specify parameters for mdadm (for example, in /etc/rc.conf). I've tired to do changes in /etc/rc.sysinit after every update.
There are a lot of usefull parameters for mdadm, for example "--no-degraded" - don't start array if at least one disk failed.
Also init script have incorrect processing of result code - new kernel can assemble arrays automaticly, so in this case "#mdadm -As" returns 2.

Additional info:
* package version(s)
$ pacman -Qo /etc/rc.sysinit
/etc/rc.sysinit is owned by initscripts 2010.06-2
$ pacman -Qo `which mdadm`
/sbin/mdadm is owned by mdadm 3.1.2-2
This task depends upon

Closed by  Tom Gundersen (tomegun)
Sunday, 10 April 2011, 02:21 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See last comment by Seblu
Comment by Pierre Schmitz (Pierre) - Monday, 08 November 2010, 11:16 GMT
There should also be a proper shutdown script to stop the raid array before poweroff. Maybe a good way would be to implement or add it nearba run_hook shutdown_poweroff.
Comment by Sébastien Luttringer (seblu) - Monday, 28 March 2011, 23:09 GMT
Do you think this bug should still be in the agenda? newer kernel mount automatically mdadm devices (i don't know if this behaviour can be turn off).
Comment by Tom Gundersen (tomegun) - Monday, 28 March 2011, 23:28 GMT
@Seb: I don't use mdadm, so it would be great if you can enlighten me. Are you saying that running mdadm --assemble --scan is not necessary on modern kernels (or even possible?), do you have a link to some documentation on this? Does this mean that mdadm can be removed from rc.sysinit sometime in the future? If the answer is "yes", then I agree that this bug should be a "Won't fix".
Comment by Roman Kosenko (kite) - Tuesday, 29 March 2011, 00:36 GMT
> newer kernel mount automatically mdadm devices (i don't know if this behaviour can be turn off).
there is kernel parameter raid=noautodetect

> do you have a link to some documentation on this?
$man md

> Does this mean that mdadm can be removed from rc.sysinit sometime in the future?
no, kernel's autodetect doesn't read /etc/mdadm.conf
Comment by Sébastien Luttringer (seblu) - Tuesday, 29 March 2011, 00:59 GMT
Recent version of kernel autostart md devices. I learn it fixing this bug https://bugs.archlinux.org/task/18440.

So we have introduce: http://projects.archlinux.org/initscripts.git/commit/?id=8b2bfa7bd0073a3a9d389242faf16483c9ec5336, which allow disabling of mdadm by initscripts and let kernel do it job.
All is well explain in linux-2.6/Documentation/md.txt

<extract>
Boot time autodetection of RAID arrays
--------------------------------------
When md is compiled into the kernel (not as module), partitions of
type 0xfd are scanned and automatically assembled into RAID arrays.
This autodetection may be suppressed with the kernel parameter
"raid=noautodetect". As of kernel 2.6.9, only drives with a type 0
superblock can be autodetected and run at boot time.
</extract>

1) Archlinux kernel have md builtin.
2) Auto detection can be disabled at kernel boot time
3) Kernel by default doesn't mount dirty raid
4) Kernel can mount dirty raid (md-mod.start_dirty_degraded=1)

IMHO, if someone wants to start his raid manually (with options), he should set kernel param raid=noautodetect and create a rc hook to assemble.

I think we should wait a release with new option USE_MDADM="no" before removing it. To see reaction of community.
Comment by Sébastien Luttringer (seblu) - Tuesday, 29 March 2011, 01:04 GMT
@kite: what makes me retissant to add this option is: we should to the same with fakeraid, btrfs, etc.
Comment by Tobias Powalowski (tpowa) - Tuesday, 29 March 2011, 05:37 GMT
Just for the record the default arch kernels don't builtin md!
All is modularized, no autodetection of kernel can work with them.
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
Comment by Tom Gundersen (tomegun) - Tuesday, 29 March 2011, 09:52 GMT
@kite: thanks for info (I had been reading "man mdadm" which was not very informative, doh!).
@tpowa: was this recently changed?  FS#18440  seems to assert that all Arch systems should have md devices preloaded, so if this has always been this way in the Arch kernel, then either the reporter failed to mention that he was using a self-compiled kernel, or there is something else assembling the arrays.

I read (and hope it is true!) that udev should/could assemble arrays. Is this enabled on Arch? Does this have any bad side effects (i.e., is mdadm.conf read, etc)?

I hope to at some point mark all mdadm, dmraid, lvm and btrfs stuff as deprecated in rc.sysinit, but then we need proper support for it in the relevant other tools (like udev).
Comment by Sébastien Luttringer (seblu) - Tuesday, 29 March 2011, 22:19 GMT
@tpowa: my bad. It's udev which start md devices.
   mdadm.png (11.3 KiB)
Comment by Sébastien Luttringer (seblu) - Sunday, 03 April 2011, 14:17 GMT
this line in /lib/udev/rules.d/64-md-raid.rules do the job
ENV{ID_FS_TYPE}=="linux_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}"

so, udev take care of creating raid array. maybe we should completly remove mdadm stuff from initscript and let udev doing this?

if i understand correctly we can also remove fakeraid enable because udev have some rules about it, but call the bad binary.
ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}"
I will investigate later.
Comment by Tom Gundersen (tomegun) - Sunday, 03 April 2011, 15:08 GMT
@seblu: thanks for looking into this. Is the bad binary a bug? I notice that fakeraid does not come with any udev rules which seems odd.
Comment by Sébastien Luttringer (seblu) - Sunday, 03 April 2011, 16:14 GMT
ok this rules added here in upstream.
http://neil.brown.name/git?p=mdadm;a=commit;h=475a01b8bce8575dd1b2ab6495e65e854702ac0e

i surprised that mdadm can handle this. I asked question on linux-raid.
Comment by Tobias Powalowski (tpowa) - Sunday, 03 April 2011, 19:52 GMT
I don't think udev can handle all things alone, the config file does much more then just assembling arrays,
You specify device names and such in it too.
For more complex devices with lvm and encrypt combined I don't think it will work.
Comment by Sébastien Luttringer (seblu) - Sunday, 03 April 2011, 23:35 GMT
Sure udev cannot handle all things alone. Especially regarding answer of Kay Sievers in ml about bluez and removing --type=failed logic.
But in case of soft raid, udev seems offer a smart solution.

Before developing the point, about which config file you speak? /etc/mdadm.conf?
Comment by Tobias Powalowski (tpowa) - Monday, 04 April 2011, 05:49 GMT
Yes mdadm.conf is used in initramfs if user modified it.
And is used if mdadm is called after initramfs.
Comment by Sébastien Luttringer (seblu) - Sunday, 10 April 2011, 00:26 GMT
udev rules call "mdadm -I", which take in consideration mdadm.conf. Calling mdadm from initscripts or from udev, in both cases uses mdadm.conf.

I see the following advantages to letting udev do the job:
1- Raid is created each time a raid member disk is dicovered. This escape a check of *all* drives at a given time when we calling mdadm -As.
2- This let udev upstream unmodified.
3- Assembling a raid, is creating a block file in /dev. It's the main udev job.
4- Theorically this fix the cross dependance of mounting raid over a lvm device.
5- Currently, udev rules call mdadm before initscripts. So it's working like this since a long time.

The current bugs report, ask about adding options to mdadm, for example --no-degraded.
[quote mdadm]
This is the reverse of --run in that it inhibits the startup of array unless all expected drives are
present. This is only needed with --scan, and can be used if the physical connections to devices are
not as reliable as you would like.
[/quote]
To follow spirit of this request, we should disable udev rules and adding command lines options to mdadm. This sucks.
If someone really want do this, he may remove udev rules and add an hook in initscripts.

Loading...