Am 11.02.2013 01:31, schrieb NeilBrown: > On Sat, 9 Feb 2013 21:49:47 +0100 Thomas Bächler <tho...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel