Am 11.02.2013 01:31, schrieb NeilBrown: > On Sat, 9 Feb 2013 21:49:47 +0100 Thomas Bächler <thomas@xxxxxxxxxxxxx> > 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:
signature.asc
Description: OpenPGP digital signature
