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

[Benjamin Marzinski]

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 ...
> 
> Upstream does not even ship a rule, which sets ID_FS_TYPE.
> 
> I don't know why we have 100 patches in Fedora rawhide on
> top of upstream for the multipath tools.
> 
> Seems like nobody is pushing patches upstream, or upstream is not accepting any.

Since multipath upstream doesn't have a stable branch.  The safest thing
to do is to pick a point and pull then, and just apply known stable
patches on top of it, instead of trying to keep in sync with upstream,
and repeatedly pulling down patches that break things.

But, yes, upstream currently doesn't appear to be taking patches.
Christophe hasn't responded to any of my emails recently, and and the
last patch of mine he's accepted (or even commented on) was IIRC in
September. I assume this is just temporary, and was planning to wait
until January to see if he came back.

-Ben