[systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

Benjamin Marzinski bmarzins at redhat.com
Fri Dec 5 07:02:24 PST 2014

On Fri, Dec 05, 2014 at 11:07:35AM +0100, Harald Hoyer wrote:
> On 05.12.2014 08:20, Andrei Borzenkov wrote:
> > В Thu, 04 Dec 2014 18:24:11 +0100
> > Harald Hoyer <harald at redhat.com> пишет:
> > 
> >> On 04.12.2014 18:19, Andrei Borzenkov wrote:
> >>> В Thu, 04 Dec 2014 15:14:00 +0100
> >>> Harald Hoyer <harald at redhat.com> пишет:
> >>>
> >>>> On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
> >>>>> On Thu, Dec 04, 2014 at 12:57:36PM +0100, harald at redhat.com wrote:
> >>>>>> From: Harald Hoyer <harald at redhat.com>
> >>>>>>
> >>>>>> If ID_FS_TYPE of a parent is already set,
> >>>>>> then it's something like "linux_raid_member" or "mpath_member"
> >>>>>> and the disk is already in use, so don't handle the partitions
> >>>>> Is this trying to fix an existing problem?
> >>>>
> >>>> yes, for "mpath_member" disk partitions, we should never ever advertise the
> >>>> /dev/disk/by* symlinks or set SYSTEMD_READY for it.
> >>>
> >>> How is it going to work? I mean, first we get device, then it is
> >>> processed by multipathd. At the time rules are processed by udev, we
> >>> have no idea whether it will be added to mpath later.
> >>
> >> For the disk, we should/must the flag set immediately in 62-multipath.rules.
> >>
> > 
> > OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to
> > "none", but the effect should be the same. I do not see this rule in
> > multipath-tools ... should not it be unified across distros?
> Yeah, should be ...

The redhat multipath rules assume that you are using find_multipaths.
This isn't upstream yet. Hannes has rejected the patch twice, for
reasons I don't really understand. He recently requested that I push it
again, and I have in my last batch of patches.  But Christophe hasn't
pulled them, or any of my recent patches.  But that isn't a big deal.
It just involes changing "multipath -c" to "multipath -i -c" to ignore
the wwids file and just use the blacklist, when claiming a block device.

The bigger reason I've held off from pushing the rules is that, in order
to keep from doing all the 'multipath -c' work on every change event
(which could cause problems for udev if there were a large number of
events coming in at the same time) I added a timestamp that lets
multipathd know if /etc/multipath.conf or /etc/multipath/wwids has
changed.  However theres no way to compare db values in udev rules.

for instance

ENV{TEST_A}="$env{TEST_B}"  lets you assign the value of TEST_B to TEST_A


ENV{TEST_A}=="foo"  lets you compare the value of TEST_A to "foo"


ENV{TEST_A}=="$env{TEST_B}"  doesn't work.  You can't compare
the value of TEST_B to the value of TEST_A

So multipath has to hackily work around this in the udev rules.  I filed
a bug for this,


and I don't want to push in hacky code without at least an answer why
this can't be solved in udev.


More information about the systemd-devel mailing list