Re: [PATCHv2 2/2] udev: Fix order of execution of the md rules

["Thomas Bächler" <thomas@archlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

Am 11.02.2013 01:31, schrieb NeilBrown:
> On Sat,  9 Feb 2013 21:49:47 +0100 Thomas Bächler <thomas@archlinux.org>
> wrote:
> 
>> 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]