Am 11.02.2013 01:31, schrieb NeilBrown:

On Sat,  9 Feb 2013 21:49:47 +0100 Thomas Bächler [off-list ref]
wrote:

quoted

Right now, the rules that run blkid on raid arrays are executed after
the assembly rules. This means incremental assembly will always fail
when raid arrays are again physical components of raid arrays.

I'm not at all against splitting the udev rules into two files, but your
reasoning seems a bit odd and I want to be sure that I understand.

We run "mdadm -I" based on the contents of ID_FS_TYPE, and ID_FS_TYPE is set
by "blkid", which is called after the "mdadm -I" rules.  So why do they work
at all?

If a new device, say /dev/md0 is added by udev, before the patch, the
rules would do the following:

1) go to md_inc_skip, because ID_FS_TYPE is unset, thus skip incremental
assembly.
2) call blkid and set ID_FS_TYPE

If ID_FS_TYPE is again linux_raid_member, then it would have been
necessary to call mdadm -I for /dev/md0 here.

This is probably what happens here: https://bugs.archlinux.org/task/32558

The short version is: The reporter joins three disks as a RAID0 (md2),
then combines md2 with another hard drive as RAID1.

With my changes, incremental assembly should work in this case, because
ID_FS_TYPE is set before incremental assembly tests for it.

Presumably something else is calling "blkid" ?
That seems to be "persistent-storage.rules"  which calls "blkid" on some
devices, but not on others.  That seems sub-optimal.   It is probably
reasonable that it skips "sr*" (which is explicit) but for us it is
unfortunate that it skips "md*".

Yes, udev's standard rules skip md*, and I do not know why.

I cannot see a good reason for persistent-storage-rules to skip 'md' devices,
so I would suggest that the best way to fix the problem is the fix that
rules file.  Then we could remove the "blkid" call from the md rules which is
nice as it removes duplication.

CC'ing Kay here. Kay, is there a good reason to skip md* in
60-persistent-storage.rules?

We could still split the md rules files, but I would rather do that because
it was a good and clean thing to do, not do that because it helps work around
a short-coming in some other rules files.

The "good reason" is that the rules fulfill two different tasks:
1) Apply incremental assembly to RAID members.
2) Set properties on RAID arrays.
Two tasks means two separate files, so you can easily disable or
override only one of them.