[systemd-devel] [PATCHv2 2/2] udev: Fix order of execution of the md rules
Thomas Bächler
thomas at archlinux.org
Mon Feb 11 02:01:53 PST 2013
Am 11.02.2013 01:31, schrieb NeilBrown:
> On Sat, 9 Feb 2013 21:49:47 +0100 Thomas Bächler <thomas at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130211/ea268c02/attachment.pgp>
More information about the systemd-devel
mailing list