* multipath-0.5.0 still provides broken udev rules
@ 2016-04-25 10:52 Peter Volkov
2016-04-25 10:58 ` Zdenek Kabelac
2016-04-25 15:04 ` multipath-0.5.0 still provides broken udev rules Hannes Reinecke
0 siblings, 2 replies; 23+ messages in thread
From: Peter Volkov @ 2016-04-25 10:52 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --]
Hi, guys.
There is a problem: udev does not create partitions for multipath devices
in case I use kpartx.rules provided with multipath sources. I found that
udev always go to kpartx_end after following line of rules:
ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
There is 8 (!!!) years old thread that discusses this problem:
https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html
So what is the current state? Should we fix udev rules for multipath or
should we create better patch for dmsetup.c? Meanwhile I've copied
multipath.rules from redhat and partitions are created as they should.
With best regards,
--
Peter.
[-- Attachment #1.2: Type: text/html, Size: 1622 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 10:52 multipath-0.5.0 still provides broken udev rules Peter Volkov @ 2016-04-25 10:58 ` Zdenek Kabelac 2016-04-25 12:10 ` Peter Volkov 2016-04-25 15:04 ` multipath-0.5.0 still provides broken udev rules Hannes Reinecke 1 sibling, 1 reply; 23+ messages in thread From: Zdenek Kabelac @ 2016-04-25 10:58 UTC (permalink / raw) To: Peter Volkov, dm-devel On 25.4.2016 12:52, Peter Volkov wrote: > Hi, guys. > > There is a problem: udev does not create partitions for multipath devices in > case I use kpartx.rules provided with multipath sources. I found that udev > always go to kpartx_end after following line of rules: > ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" Hi Just curious - what would you want to do with inactive table??? You cannot read/scan such device ? > > There is 8 (!!!) years old thread that discusses this problem: > https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html > > So what is the current state? Should we fix udev rules for multipath or should > we create better patch for dmsetup.c? Meanwhile I've copied multipath.rules > from redhat and partitions are created as they should. What is the exact problem you do have/see ? Can you describe in some single repeatable steps a reproducer ? Which distro are you talking about (Fedora ? Debian ??) Have you opened any bugzilla anywhere ? Regard Zdenek ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 10:58 ` Zdenek Kabelac @ 2016-04-25 12:10 ` Peter Volkov 2016-04-25 12:32 ` Zdenek Kabelac 0 siblings, 1 reply; 23+ messages in thread From: Peter Volkov @ 2016-04-25 12:10 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: dm-devel [-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --] On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote: > On 25.4.2016 12:52, Peter Volkov wrote: >> >> There is a problem: udev does not create partitions for multipath devices >> in >> case I use kpartx.rules provided with multipath sources. I found that udev >> always go to kpartx_end after following line of rules: >> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" >> > > Just curious - what would you want to do with inactive table??? > Actually don't understand what's this table and what's wrong with that. There is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such variable in udev rules file that comes with multipath sources: http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD > You cannot read/scan such device ? The problem I have - multipath with udev's help creates /dev/mapper/mpatha block device but does not create devices for partitions, e.g. /dev/mapper/mpatha1. I found that this happens due to udev rule mentioned above. After execution rule on line 10 (*ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"*) udev goes directly to kpartx_end and rule on line 45 (..."/sbin/kpartx -u -p -part /dev/$name") is never executed. > There is 8 (!!!) years old thread that discusses this problem: >> https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html >> >> So what is the current state? Should we fix udev rules for multipath or >> should >> we create better patch for dmsetup.c? Meanwhile I've copied >> multipath.rules >> from redhat and partitions are created as they should. >> > > > What is the exact problem you do have/see ? Can you describe in some single repeatable steps a reproducer ? > Install udev rules file from mutlipath tools and see that partitions are not created. > Which distro are you talking about (Fedora ? Debian ??) > That's Gentoo. But I think any distro that uses whatever upstream prepares have this problem. > Have you opened any bugzilla anywhere ? > Not yet. I'd like to understand what needs to be done first. -- Peter. [-- Attachment #1.2: Type: text/html, Size: 4429 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:10 ` Peter Volkov @ 2016-04-25 12:32 ` Zdenek Kabelac 2016-04-25 12:52 ` Peter Volkov 2016-04-25 12:56 ` Christophe Varoqui 0 siblings, 2 replies; 23+ messages in thread From: Zdenek Kabelac @ 2016-04-25 12:32 UTC (permalink / raw) To: Peter Volkov; +Cc: dm-devel On 25.4.2016 14:10, Peter Volkov wrote: > On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com > <mailto:zkabelac@redhat.com>> wrote: > > On 25.4.2016 12:52, Peter Volkov wrote: > > There is a problem: udev does not create partitions for multipath > devices in > case I use kpartx.rules provided with multipath sources. I found that udev > always go to kpartx_end after following line of rules: > ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" > > > Just curious - what would you want to do with inactive table??? > > > Actually don't understand what's this table and what's wrong with that. There > is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such > variable in udev rules file that comes with multipath sources: > http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD So you would need to figure out which rules would have set DM_TABLE_STATE before ? (I assume such have never existed...) In Fedora/RHEL these kpartx.rules are not packaged as they are likely some 'ancient' rules - IMHO most of that file is useless on today's distros. (Unsure about dm-wwn logic???) So it's rather question for upstream kpartx maintainer why these rules are not maintained in any way. Vars like DM_TABLE_STATE are simply not created by dm rules. kpartx rules comes from year 2007, while dm rules started to be maintained in 2009 - that may explain few things as well... > That's Gentoo. But I think any distro that uses whatever upstream prepares > have this problem. > > Have you opened any bugzilla anywhere ? > > > Not yet. I'd like to understand what needs to be done first. > Likely Gentoo should not install obsoleted udev rules file. Regards Zdenek PS: I could be wrong here - since I've nothing in common with multipath, so in such case - feel free to correct me.... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:32 ` Zdenek Kabelac @ 2016-04-25 12:52 ` Peter Volkov 2016-04-25 12:56 ` Christophe Varoqui 1 sibling, 0 replies; 23+ messages in thread From: Peter Volkov @ 2016-04-25 12:52 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: dm-devel [-- Attachment #1.1: Type: text/plain, Size: 1967 bytes --] On Mon, Apr 25, 2016 at 3:32 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote: > On 25.4.2016 14:10, Peter Volkov wrote: > >> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com >> <mailto:zkabelac@redhat.com>> wrote: >> >> On 25.4.2016 12:52, Peter Volkov wrote: >> >> There is a problem: udev does not create partitions for multipath >> devices in >> case I use kpartx.rules provided with multipath sources. I found >> that udev >> always go to kpartx_end after following line of rules: >> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" >> >> Actually don't understand what's this table and what's wrong with that. >> There >> is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such >> variable in udev rules file that comes with multipath sources: >> >> http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD >> > > > So you would need to figure out which rules would have set DM_TABLE_STATE > before ? (I assume such have never existed...) > There was a patch suggested for dmsetup: https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html So it's rather question for upstream kpartx maintainer why these rules > are not maintained in any way. > Yup, that's why I'm here. kpartx rules comes from year 2007, while dm rules started to be maintained > in 2009 - that may explain few things as well... Then your suggestion is to fix udev rules that comes with multipath. Ok. That's Gentoo. But I think any distro that uses whatever upstream prepares >> have this problem. >> > > Likely Gentoo should not install obsoleted udev rules file. > That's true. Yet I'm not talking about Gentoo here, but about config file that comes with multipath sources and according to multipath homepage this mailing list is a right place for such discussions. Please, correct me if I'm wrong. -- Peter. [-- Attachment #1.2: Type: text/html, Size: 4436 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:32 ` Zdenek Kabelac 2016-04-25 12:52 ` Peter Volkov @ 2016-04-25 12:56 ` Christophe Varoqui 2016-04-25 14:15 ` Peter Volkov ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Christophe Varoqui @ 2016-04-25 12:56 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: device-mapper development, Peter Volkov [-- Attachment #1.1: Type: text/plain, Size: 2574 bytes --] Hi, Those example udev rules are indeed unmaintained and should be removed not to confuse distributors. Distributors can't be asked to agree on a common udev ruleset. Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? Best regards, On Mon, Apr 25, 2016 at 2:32 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote: > On 25.4.2016 14:10, Peter Volkov wrote: > >> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com >> <mailto:zkabelac@redhat.com>> wrote: >> >> On 25.4.2016 12:52, Peter Volkov wrote: >> >> There is a problem: udev does not create partitions for multipath >> devices in >> case I use kpartx.rules provided with multipath sources. I found >> that udev >> always go to kpartx_end after following line of rules: >> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" >> >> >> Just curious - what would you want to do with inactive table??? >> >> >> Actually don't understand what's this table and what's wrong with that. >> There >> is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such >> variable in udev rules file that comes with multipath sources: >> >> http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD >> > > > So you would need to figure out which rules would have set DM_TABLE_STATE > before ? (I assume such have never existed...) > > In Fedora/RHEL these kpartx.rules are not packaged as they are likely > some 'ancient' rules - IMHO most of that file is useless on today's > distros. > (Unsure about dm-wwn logic???) > > So it's rather question for upstream kpartx maintainer why these rules > are not maintained in any way. > > Vars like DM_TABLE_STATE are simply not created by dm rules. > > kpartx rules comes from year 2007, while dm rules started to be maintained > in 2009 - that may explain few things as well... > > That's Gentoo. But I think any distro that uses whatever upstream prepares >> have this problem. >> >> Have you opened any bugzilla anywhere ? >> >> >> Not yet. I'd like to understand what needs to be done first. >> >> > Likely Gentoo should not install obsoleted udev rules file. > > Regards > > Zdenek > > PS: I could be wrong here - since I've nothing in common with multipath, > so in such case - feel free to correct me.... > > > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel > [-- Attachment #1.2: Type: text/html, Size: 4003 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:56 ` Christophe Varoqui @ 2016-04-25 14:15 ` Peter Volkov 2016-04-25 17:38 ` Benjamin Marzinski 2016-04-25 20:14 ` Xose Vazquez Perez 2 siblings, 0 replies; 23+ messages in thread From: Peter Volkov @ 2016-04-25 14:15 UTC (permalink / raw) To: Christophe Varoqui; +Cc: device-mapper development, Zdenek Kabelac [-- Attachment #1.1: Type: text/plain, Size: 813 bytes --] On Mon, Apr 25, 2016 at 3:56 PM, Christophe Varoqui < christophe.varoqui@opensvc.com> wrote: > Distributors can't be asked to agree on a common udev ruleset. > Of course, there is no pressure on downstream distributor on what configuration/udev rules should be used. Yet it's always good to have upstream hand for such things. Lot's of packages (lvm/systemd/networkmanager/...) come with an upstream suggested udev rules. Should we avoid use of that udev rules? I don't think so. Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example > ? > Since these rules are broken it good idea to drop this file to avoid confusion. Yet it's good idea to document some general ideas of what needs to be done with udev to setup fully working multipath configuration. -- Peter. [-- Attachment #1.2: Type: text/html, Size: 1478 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:56 ` Christophe Varoqui 2016-04-25 14:15 ` Peter Volkov @ 2016-04-25 17:38 ` Benjamin Marzinski 2016-04-26 5:43 ` Hannes Reinecke 2016-04-25 20:14 ` Xose Vazquez Perez 2 siblings, 1 reply; 23+ messages in thread From: Benjamin Marzinski @ 2016-04-25 17:38 UTC (permalink / raw) To: Christophe Varoqui Cc: device-mapper development, Peter Volkov, Zdenek Kabelac On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: > Hi, > Those example udev rules are indeed unmaintained and should be removed not > to confuse distributors. > Distributors can't be asked to agree on a common udev ruleset. Ben, > Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? I am personally fine with kpartx.rules being deleted. Red Hat doesn't package it. -Ben > Best regards, > On Mon, Apr 25, 2016 at 2:32 PM, Zdenek Kabelac <[1]zkabelac@redhat.com> > wrote: > > On 25.4.2016 14:10, Peter Volkov wrote: > > On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac > <[2]zkabelac@redhat.com > <mailto:[3]zkabelac@redhat.com>> wrote: > > On 25.4.2016 12:52, Peter Volkov wrote: > > There is a problem: udev does not create partitions for > multipath > devices in > case I use kpartx.rules provided with multipath sources. I > found that udev > always go to kpartx_end after following line of rules: > ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" > > Just curious - what would you want to do with inactive table??? > > Actually don't understand what's this table and what's wrong with > that. There > is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is > such > variable in udev rules file that comes with multipath sources: > [4]http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD > > So you would need to figure out which rules would have set > DM_TABLE_STATE before ? (I assume such have never existed...) > > In Fedora/RHEL these kpartx.rules are not packaged as they are likely > some 'ancient' rules - IMHO most of that file is useless on today's > distros. > (Unsure about dm-wwn logic???) > > So it's rather question for upstream kpartx maintainer why these rules > are not maintained in any way. > > Vars like DM_TABLE_STATE are simply not created by dm rules. > > kpartx rules comes from year 2007, while dm rules started to be > maintained in 2009 - that may explain few things as well... > > That's Gentoo. But I think any distro that uses whatever upstream > prepares > have this problem. > > Have you opened any bugzilla anywhere ? > > Not yet. I'd like to understand what needs to be done first. > > Likely Gentoo should not install obsoleted udev rules file. > > Regards > > Zdenek > PS: I could be wrong here - since I've nothing in common with multipath, > so in such case - feel free to correct me.... > > -- > dm-devel mailing list > [5]dm-devel@redhat.com > [6]https://www.redhat.com/mailman/listinfo/dm-devel > > References > > Visible links > 1. mailto:zkabelac@redhat.com > 2. mailto:zkabelac@redhat.com > 3. mailto:zkabelac@redhat.com > 4. http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD > 5. mailto:dm-devel@redhat.com > 6. https://www.redhat.com/mailman/listinfo/dm-devel > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 17:38 ` Benjamin Marzinski @ 2016-04-26 5:43 ` Hannes Reinecke 2016-04-26 8:39 ` Zdenek Kabelac 0 siblings, 1 reply; 23+ messages in thread From: Hannes Reinecke @ 2016-04-26 5:43 UTC (permalink / raw) To: dm-devel On 04/25/2016 07:38 PM, Benjamin Marzinski wrote: > On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >> Hi, >> Those example udev rules are indeed unmaintained and should be removed not >> to confuse distributors. >> Distributors can't be asked to agree on a common udev ruleset. Ben, >> Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? > > I am personally fine with kpartx.rules being deleted. Red Hat doesn't > package it. > Well, we do. We use kpartx to generate partitions for multipath and dmraid, so we do need this rule. Please do not delete it; if so I will only have to re-add it again in a SUSE-specific patch. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-26 5:43 ` Hannes Reinecke @ 2016-04-26 8:39 ` Zdenek Kabelac 2016-04-26 8:47 ` Hannes Reinecke 0 siblings, 1 reply; 23+ messages in thread From: Zdenek Kabelac @ 2016-04-26 8:39 UTC (permalink / raw) To: dm-devel On 26.4.2016 07:43, Hannes Reinecke wrote: > On 04/25/2016 07:38 PM, Benjamin Marzinski wrote: >> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >>> Hi, >>> Those example udev rules are indeed unmaintained and should be removed not >>> to confuse distributors. >>> Distributors can't be asked to agree on a common udev ruleset. Ben, >>> Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? >> >> I am personally fine with kpartx.rules being deleted. Red Hat doesn't >> package it. >> > Well, we do. We use kpartx to generate partitions for multipath and > dmraid, so we do need this rule. > Please do not delete it; if so I will only have to re-add it again > in a SUSE-specific patch. Hi Can you please elaborate what is the 'specific' need of SUSE for patch? AFAIK there should be no need for it - all identifiers are not tracked by 10-dm.rules It has whole logic about device state built-in. So what exactly would you need to trace in kpartx.rules ? Regards Zdenek ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-26 8:39 ` Zdenek Kabelac @ 2016-04-26 8:47 ` Hannes Reinecke 2016-04-26 9:19 ` Zdenek Kabelac 0 siblings, 1 reply; 23+ messages in thread From: Hannes Reinecke @ 2016-04-26 8:47 UTC (permalink / raw) To: dm-devel On 04/26/2016 10:39 AM, Zdenek Kabelac wrote: > On 26.4.2016 07:43, Hannes Reinecke wrote: >> On 04/25/2016 07:38 PM, Benjamin Marzinski wrote: >>> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >>>> Hi, >>>> Those example udev rules are indeed unmaintained and should >>>> be removed not >>>> to confuse distributors. >>>> Distributors can't be asked to agree on a common udev >>>> ruleset. Ben, >>>> Hannes, Xosé, Peter are you ok with my deleting the udev >>>> rules example ? >>> >>> I am personally fine with kpartx.rules being deleted. Red Hat >>> doesn't >>> package it. >>> >> Well, we do. We use kpartx to generate partitions for multipath and >> dmraid, so we do need this rule. >> Please do not delete it; if so I will only have to re-add it again >> in a SUSE-specific patch. > > Hi > > Can you please elaborate what is the 'specific' need of SUSE for patch? > > AFAIK there should be no need for it - all identifiers are not > tracked by > 10-dm.rules > > It has whole logic about device state built-in. > > So what exactly would you need to trace in kpartx.rules ? > We use kpartx.rules to call 'kpartx' itself for creating the partition devices on top of any multipath or dmraid devices. If that logic has been moved into other, generic, device-mapper rules please let me know. But until then we need the kpartx.rules. file. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-26 8:47 ` Hannes Reinecke @ 2016-04-26 9:19 ` Zdenek Kabelac 0 siblings, 0 replies; 23+ messages in thread From: Zdenek Kabelac @ 2016-04-26 9:19 UTC (permalink / raw) To: dm-devel, Hannes Reinecke On 26.4.2016 10:47, Hannes Reinecke wrote: > On 04/26/2016 10:39 AM, Zdenek Kabelac wrote: >> On 26.4.2016 07:43, Hannes Reinecke wrote: >>> On 04/25/2016 07:38 PM, Benjamin Marzinski wrote: >>>> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >>>>> Hi, >>>>> Those example udev rules are indeed unmaintained and should >>>>> be removed not >>>>> to confuse distributors. >>>>> Distributors can't be asked to agree on a common udev >>>>> ruleset. Ben, >>>>> Hannes, Xosé, Peter are you ok with my deleting the udev >>>>> rules example ? >>>> >>>> I am personally fine with kpartx.rules being deleted. Red Hat >>>> doesn't >>>> package it. >>>> >>> Well, we do. We use kpartx to generate partitions for multipath and >>> dmraid, so we do need this rule. >>> Please do not delete it; if so I will only have to re-add it again >>> in a SUSE-specific patch. >> >> Hi >> >> Can you please elaborate what is the 'specific' need of SUSE for patch? >> >> AFAIK there should be no need for it - all identifiers are not >> tracked by >> 10-dm.rules >> >> It has whole logic about device state built-in. >> >> So what exactly would you need to trace in kpartx.rules ? >> > We use kpartx.rules to call 'kpartx' itself for creating the > partition devices on top of any multipath or dmraid devices. > > If that logic has been moved into other, generic, device-mapper > rules please let me know. > But until then we need the kpartx.rules. file. Ok, so it seems it is completely chaotic - As in RHEL/Fedora there is largely hacked mpath udev rule file, which is then responsible for using partx? While in SUSE this seems to be handled by broken old unmaintained kpartx udev rules file (as the file is useless - wondering how could do anything useful on SUSE) AFAIK seems we miss communication between Ben with Hannes here :) As logically it seem calling kpartx rule calls belong to kpartx package. However kpartx upstream rule file is for systems from 2007 year. So I'd have assumed lots of current mpath RHEL rule patches should be relocated to kpartx rules. Leaving this to you guys... Regards Zdenek ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 12:56 ` Christophe Varoqui 2016-04-25 14:15 ` Peter Volkov 2016-04-25 17:38 ` Benjamin Marzinski @ 2016-04-25 20:14 ` Xose Vazquez Perez 2016-04-26 5:53 ` Hannes Reinecke 2 siblings, 1 reply; 23+ messages in thread From: Xose Vazquez Perez @ 2016-04-25 20:14 UTC (permalink / raw) To: Christophe Varoqui, Zdenek Kabelac Cc: device-mapper development, Peter Volkov On 04/25/2016 02:56 PM, Christophe Varoqui wrote: > Those example udev rules are indeed unmaintained and should be > removed not to confuse distributors. > > Distributors can't be asked to agree on a common udev ruleset. > Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? Fine with me. Btw, are these relevant ? getuid/usb_id kpartx/kpartx_id kpartx/kpartx.rules multipath/01_udev multipath/02_multipath multipath/11-dm-mpath.rules multipath.conf.annotated multipath.conf.defaults multipath.conf.synthetic multipathd/multipathd.init.debian multipathd/multipathd.init.redhat multipathd/multipathd.init.suse multipathd/multipathd.service multipathd/multipathd.socket multipath/multipath.init.suse multipath/multipath.rules multipath-tools.spec.in -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 20:14 ` Xose Vazquez Perez @ 2016-04-26 5:53 ` Hannes Reinecke 2016-04-27 22:46 ` Benjamin Marzinski 0 siblings, 1 reply; 23+ messages in thread From: Hannes Reinecke @ 2016-04-26 5:53 UTC (permalink / raw) To: Xose Vazquez Perez, Christophe Varoqui, Zdenek Kabelac Cc: device-mapper development, Peter Volkov On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: > On 04/25/2016 02:56 PM, Christophe Varoqui wrote: > >> Those example udev rules are indeed unmaintained and should be >> removed not to confuse distributors. >> >> Distributors can't be asked to agree on a common udev ruleset. >> Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? > > Fine with me. > > Btw, are these relevant ? > > getuid/usb_id Huh? What is that doing there? It should really have been moved to the udev package ... > kpartx/kpartx_id > kpartx/kpartx.rules See above. Yes, they are relevant (at least for us) > multipath/01_udev > multipath/02_multipath Not used anymore with systemd/dracut > multipath/11-dm-mpath.rules Yep. Absolutely required. > multipath.conf.annotated > multipath.conf.defaults > multipath.conf.synthetic Actually, I never saw the need for those. Can we at least have them merged? > multipathd/multipathd.init.debian > multipathd/multipathd.init.redhat > multipathd/multipathd.init.suse Old init scripts; doubtful value. > multipathd/multipathd.service > multipathd/multipathd.socket systemd service definitions. Yes, required. > multipath/multipath.init.suse Old init script; not used anymore. > multipath/multipath.rules Yep. used for udev. > multipath-tools.spec.in > Well; due to our buildservice we have to keep a separate spec file anyway. So ATM we don't use it. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-26 5:53 ` Hannes Reinecke @ 2016-04-27 22:46 ` Benjamin Marzinski 2016-04-28 6:23 ` Hannes Reinecke 2016-05-19 15:24 ` multipath-tools: irrelevant files Xose Vazquez Perez 0 siblings, 2 replies; 23+ messages in thread From: Benjamin Marzinski @ 2016-04-27 22:46 UTC (permalink / raw) To: Hannes Reinecke Cc: Peter Volkov, device-mapper development, Xose Vazquez Perez, Zdenek Kabelac On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote: > On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: > > On 04/25/2016 02:56 PM, Christophe Varoqui wrote: > > > >> Those example udev rules are indeed unmaintained and should be > >> removed not to confuse distributors. > >> > >> Distributors can't be asked to agree on a common udev ruleset. > >> Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? > > > > Fine with me. > > > > Btw, are these relevant ? For all that I didn't comment on, I feel the same way as Hannes. > > getuid/usb_id > Huh? What is that doing there? > It should really have been moved to the udev package ... > > > kpartx/kpartx_id > > kpartx/kpartx.rules > See above. Yes, they are relevant (at least for us) Like I said, Red Hat doesn't use them. I'll post our multipath.rules shortly. > > multipath/01_udev > > multipath/02_multipath > Not used anymore with systemd/dracut > > > multipath/11-dm-mpath.rules > Yep. Absolutely required. > > > multipath.conf.annotated > > multipath.conf.defaults > > multipath.conf.synthetic > Actually, I never saw the need for those. > Can we at least have them merged? I don't think they are being kept up to date anymore. The 'defaults' information can be gotten from a running system, and it includes the changes from the config files, so it's much more useful. I have no idea what people would use 'synthetic' for besides an example of what a config would look like. And the 'annotated' information is all in the multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be happy to see them go. > > multipathd/multipathd.init.debian > > multipathd/multipathd.init.redhat > > multipathd/multipathd.init.suse > Old init scripts; doubtful value. > > > multipathd/multipathd.service > > multipathd/multipathd.socket > systemd service definitions. Yes, required. Red Hat has a slightly different multipathd.service file, and we don't ship the socket file. Since multipathd should always be running, I don't really see the need. Also, if you start multipathd manually (instead of through udev) this causes problems with multipathd not getting messages. For those interested, here's a diff of our multipath.service diff --git a/multipathd/multipathd.service b/multipathd/multipathd.service index d5f8606..1e5dfab 100644 --- a/multipathd/multipathd.service +++ b/multipathd/multipathd.service @@ -2,9 +2,10 @@ Description=Device-Mapper Multipath Device Controller Before=iscsi.service iscsid.service lvm2-activation-early.service Before=local-fs-pre.target -After=multipathd.socket +ConditionPathExists=/etc/multipath.conf +ConditionKernelCommandLine=!nompath DefaultDependencies=no -Wants=local-fs-pre.target multipathd.socket blk-availability.service +Wants=local-fs-pre.target blk-availability.service Conflicts=shutdown.target [Service] @@ -12,9 +13,9 @@ Type=notify NotifyAccess=main LimitCORE=infinity ExecStartPre=/sbin/modprobe dm-multipath +ExecStartPre=-/sbin/multipath -A ExecStart=/sbin/multipathd -d -s ExecReload=/sbin/multipathd reconfigure [Install] WantedBy=sysinit.target -Also=multipathd.socket Aside from dropping the socket, it checks that /etc/multipath.conf exists, and that the kernel wasn't started with "nompath". Also it runs "multipath -A" this reads the kernel commandline from /proc/cmdline, and adds any wwids listed as part of any mpath.wwid=<wwid> parameters. Hannes NACKed this patch, so the option isn't present upsteam. > > multipath/multipath.init.suse > Old init script; not used anymore. > > > multipath/multipath.rules > Yep. used for udev. > > > multipath-tools.spec.in > > > Well; due to our buildservice we have to keep a separate spec file > anyway. So ATM we don't use it. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Teamlead Storage & Networking > hare@suse.de +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-27 22:46 ` Benjamin Marzinski @ 2016-04-28 6:23 ` Hannes Reinecke 2016-04-28 22:10 ` Benjamin Marzinski 2016-04-28 22:45 ` multipath-0.5.0 still provides broken udev rules Benjamin Marzinski 2016-05-19 15:24 ` multipath-tools: irrelevant files Xose Vazquez Perez 1 sibling, 2 replies; 23+ messages in thread From: Hannes Reinecke @ 2016-04-28 6:23 UTC (permalink / raw) To: Benjamin Marzinski Cc: Peter Volkov, device-mapper development, Xose Vazquez Perez, Zdenek Kabelac On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: > On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote: >> On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: >>> On 04/25/2016 02:56 PM, Christophe Varoqui wrote: >>> >>>> Those example udev rules are indeed unmaintained and should be >>>> removed not to confuse distributors. >>>> >>>> Distributors can't be asked to agree on a common udev ruleset. >>>> Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? >>> >>> Fine with me. >>> >>> Btw, are these relevant ? > > For all that I didn't comment on, I feel the same way as Hannes. > >>> getuid/usb_id >> Huh? What is that doing there? >> It should really have been moved to the udev package ... >> >>> kpartx/kpartx_id >>> kpartx/kpartx.rules >> See above. Yes, they are relevant (at least for us) > > Like I said, Red Hat doesn't use them. I'll post our multipath.rules > shortly. > Which would be cool. I was actually hoping to meet you in Raleigh last week, but then it didn't work out. >>> multipath/01_udev >>> multipath/02_multipath >> Not used anymore with systemd/dracut >> >>> multipath/11-dm-mpath.rules >> Yep. Absolutely required. >> >>> multipath.conf.annotated >>> multipath.conf.defaults >>> multipath.conf.synthetic >> Actually, I never saw the need for those. >> Can we at least have them merged? > > I don't think they are being kept up to date anymore. The 'defaults' > information can be gotten from a running system, and it includes the > changes from the config files, so it's much more useful. I have no idea > what people would use 'synthetic' for besides an example of what a > config would look like. And the 'annotated' information is all in the > multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be > happy to see them go. > Couldn't agree more. Let's drop them. >>> multipathd/multipathd.init.debian >>> multipathd/multipathd.init.redhat >>> multipathd/multipathd.init.suse >> Old init scripts; doubtful value. >> >>> multipathd/multipathd.service >>> multipathd/multipathd.socket >> systemd service definitions. Yes, required. > > Red Hat has a slightly different multipathd.service file, and we don't > ship the socket file. Since multipathd should always be running, I > don't really see the need. Also, if you start multipathd manually > (instead of through udev) this causes problems with multipathd not > getting messages. > Hmm. Actually, I quite like the systemd integration; it allows me to signal the internal multipathd state back to systemd: # systemctl status multipathd multipathd.service - Device-Mapper Multipath Device Controller Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled) Active: active (running) since Wed 2016-04-27 12:39:59 CEST; 19h ago Main PID: 6913 (multipathd) Status: "idle" CGroup: /system.slice/multipathd.service └─6913 /sbin/multipathd -d -s Which I find quite neat. And I guess we should be able to overcome the manually started issue by checking if the socket is present, and just execute a 'reconfigure' command if so. Let me see ... > For those interested, here's a diff of our multipath.service > > diff --git a/multipathd/multipathd.service > b/multipathd/multipathd.service > index d5f8606..1e5dfab 100644 > --- a/multipathd/multipathd.service > +++ b/multipathd/multipathd.service > @@ -2,9 +2,10 @@ > Description=Device-Mapper Multipath Device Controller > Before=iscsi.service iscsid.service lvm2-activation-early.service > Before=local-fs-pre.target > -After=multipathd.socket > +ConditionPathExists=/etc/multipath.conf > +ConditionKernelCommandLine=!nompath > DefaultDependencies=no > -Wants=local-fs-pre.target multipathd.socket blk-availability.service > +Wants=local-fs-pre.target blk-availability.service > Conflicts=shutdown.target > > [Service] > @@ -12,9 +13,9 @@ Type=notify > NotifyAccess=main > LimitCORE=infinity > ExecStartPre=/sbin/modprobe dm-multipath > +ExecStartPre=-/sbin/multipath -A > ExecStart=/sbin/multipathd -d -s > ExecReload=/sbin/multipathd reconfigure > > [Install] > WantedBy=sysinit.target > -Also=multipathd.socket > > > Aside from dropping the socket, it checks that /etc/multipath.conf > exists, and that the kernel wasn't started with "nompath". Also it runs > "multipath -A" this reads the kernel commandline from /proc/cmdline, and > adds any wwids listed as part of any mpath.wwid=<wwid> parameters. > Hannes NACKed this patch, so the option isn't present upsteam. > > Hmm. Actually, I do like the 'nompath' checking; we do lack the capability of switching off multipath from the kernel commandline ATM. So yes, we should be including that bit. As for /etc/multipath.conf ... The original setup has been shipping without any multipath.conf file. So I would be okay with this change if we can guarantee that /etc/multipath.conf will always be existing. Seeing that you're running 'multipath -A' to add any wwids, wouldn't that be sufficient? IE why do we need the check for /etc/multipath.conf here; couldn't we make 'multipath -A' return non-zero to avoid multipathd to be started? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-28 6:23 ` Hannes Reinecke @ 2016-04-28 22:10 ` Benjamin Marzinski 2016-05-11 18:46 ` Distributions mpt code Xose Vazquez Perez 2016-04-28 22:45 ` multipath-0.5.0 still provides broken udev rules Benjamin Marzinski 1 sibling, 1 reply; 23+ messages in thread From: Benjamin Marzinski @ 2016-04-28 22:10 UTC (permalink / raw) To: Hannes Reinecke Cc: Peter Volkov, device-mapper development, Xose Vazquez Perez, Zdenek Kabelac On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote: > On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: > > Like I said, Red Hat doesn't use them. I'll post our multipath.rules > > shortly. > > > Which would be cool. > I was actually hoping to meet you in Raleigh last week, but then it > didn't work out. > Here is a heavily commented copy of our rules file. ---------- SUBSYSTEM!="block", GOTO="end_mpath" ACTION!="add|change", GOTO="end_mpath" # If /etc/multipath.conf doesn't exist or multipathing is disabled # on the kernel commandline, we do nothing. IMPORT{cmdline}="nompath" ENV{nompath}=="?*", GOTO="end_mpath" TEST!="/etc/multipath.conf", GOTO="end_mpath" ENV{DEVTYPE}=="partition", IMPORT{parent}="DM_MULTIPATH_DEVICE_PATH" ENV{DM_MULTIPATH_DEVICE_PATH}=="1", ENV{ID_FS_TYPE}="mpath_member", \ GOTO="end_mpath" ENV{MPATH_SBIN_PATH}="/sbin" TEST!="$env{MPATH_SBIN_PATH}/multipath", ENV{MPATH_SBIN_PATH}="/usr/sbin" # I know that we run the multipath rules later that SUSE does (after blkid # runs, for one thing), but I've never seen the issue that caused Hannes to # add the -u option. I don't see any reason why we couldn't use it however. # # Also, we only unconditionally check if the device is a multipath device # on addition, because it takes a while, and we've run into issues where # udev times out if we do it on every change event. ACTION=="add", ENV{DM_MULTIPATH_DEVICE_PATH}!="1", \ PROGRAM=="$env{MPATH_SBIN_PATH}/multipath -c $tempnode", \ ENV{DM_MULTIPATH_DEVICE_PATH}="1", ENV{ID_FS_TYPE}="mpath_member" ACTION!="change", GOTO="update_timestamp" # Load some variables from the database. The new ones will get explained # down below IMPORT{db}="DM_MULTIPATH_TIMESTAMP" IMPORT{db}="DM_MULTIPATH_DEVICE_PATH" IMPORT{db}="DM_MULTIPATH_WIPE_PARTS" IMPORT{db}="DM_MULTIPATH_NEED_KPARTX" # o.k. this whole next part is so hacky, it will make your eyes bleed. # The idea is sound, however. Like I mentioned above, I was seeing udev # timeout issues when I checked the path on every change event. My idea # to stop this was to have multipathd write out a timestamp when it # starts, and update this whenever a new path is added to the wwids file # or the configuration is reload. If neither of these thing has happened, # then rechecking the path will give you the same answer as before, so # it's not necessary. The the udev rules could read in the timestamp file, # check it against the existing timestamp, and only run this check if # the timestamp was different. The problem is that there is no way to do # that in the udev rules. You can compare variables to constants. You # can assign variables to other variables, but you can't compare # variables to other variables. I've filed a bug and sent emails about this # to the udev people, but I haven't gotten any response. So, as a # workaround, I added a multipath option, -T, which does the timestamp # comparison as soon as multipath starts up, and if they're equal, simply # returns the value you passed in with the timestamp. It's not as fast as # not execing multipath at all, but it is enough faster to fix the issue # I was seeing. But this should really be fixed in the udev rules, not # in multipath. That's why I've never posted this upstream. It's a hack. # # But the general idea here is that this is where multipath checks devices # on change events instead of add events. PROGRAM=="$env{MPATH_SBIN_PATH}/multipath -T $env{DM_MULTIPATH_TIMESTAMP}:$env{DM_MULTIPATH_DEVICE_PATH} -c $env{DEVNAME}", \ ENV{DM_MULTIPATH_DEVICE_PATH}="1", ENV{ID_FS_TYPE}="mpath_member", \ GOTO="update_timestamp" # If the device isn't part of a multipath device, clear these ENV{DM_MULTIPATH_DEVICE_PATH}="" ENV{DM_MULTIPATH_WIPE_PARTS}="" LABEL="update_timestamp" # This deletes the partition devnodes from any multipath path device. We want # to be careful to only run this once. If the users recreates the partition # devices for some reason, we don't want to keep blowing them away. That's why # we set DM_MULTIPATH_WIPE_PARTS and import it on future events. ENV{DM_MULTIPATH_DEVICE_PATH}=="1", ENV{DM_MULTIPATH_WIPE_PARTS}!="1", \ ENV{DM_MULTIPATH_WIPE_PARTS}="1", \ RUN+="/sbin/partx -d --nr 1-1024 $env{DEVNAME}" # this sets DM_MULTIPATH_TIMESTAMP IMPORT{file}="/run/multipathd/timestamp" LABEL="check_kpartx" # This is where we create the kpartx partitions KERNEL!="dm-*", GOTO="end_mpath" # This sets the link priority for all multipath and kpartx devices # so that udev creates the /dev/disk/by-* symlinks to them instead of # to the path devices. ENV{DM_UUID}=="mpath-?*|part[0-9]*-mpath-?*", OPTIONS+="link_priority=10" ACTION!="change", GOTO="end_mpath" ENV{DM_UUID}!="mpath-?*", GOTO="end_mpath" # We don't want to run kpartx on every change event (which will happen # whenever multipathd reloads the table). So only run it in the same # situations where lvm would scan the device. However, sometimes # multipath is suspended when this happens. In that case, we use # DM_MULTIPATH_NEED_KPARTX to remember that we need to run kpartx # when the next event is generated (and since the device is suspended # the next even should be arriving shortly) ENV{DM_ACTIVATION}=="1", ENV{DM_MULTIPATH_NEED_KPARTX}="1" ENV{DM_SUSPENDED}=="1", GOTO="end_mpath" ENV{DM_ACTION}=="PATH_FAILED", GOTO="end_mpath" ENV{DM_ACTIVATION}!="1", ENV{DM_MULTIPATH_NEED_KPARTX}!="1", GOTO="end_mpath" RUN+="$env{MPATH_SBIN_PATH}/kpartx -a $tempnode", \ ENV{DM_MULTIPATH_NEED_KPARTX}="" LABEL="end_mpath" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Distributions mpt code 2016-04-28 22:10 ` Benjamin Marzinski @ 2016-05-11 18:46 ` Xose Vazquez Perez 0 siblings, 0 replies; 23+ messages in thread From: Xose Vazquez Perez @ 2016-05-11 18:46 UTC (permalink / raw) To: device-mapper development; +Cc: Ritesh Raj Sarraf On 04/29/2016 12:10 AM, Benjamin Marzinski wrote: > On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote: >> On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: >>> Like I said, Red Hat doesn't use them. I'll post our multipath.rules >>> shortly. >>> >> Which would be cool. >> I was actually hoping to meet you in Raleigh last week, but then it >> didn't work out. >> > Here is a heavily commented copy of our rules file. FYI, distributions repositories of MPT are at: openSUSE/SLES: https://github.com/hreinecke/multipath-tools Fedora/RH: http://pkgs.fedoraproject.org/cgit/rpms/device-mapper-multipath.git/ Debian: https://anonscm.debian.org/git/pkg-lvm/multipath-tools.git ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-28 6:23 ` Hannes Reinecke 2016-04-28 22:10 ` Benjamin Marzinski @ 2016-04-28 22:45 ` Benjamin Marzinski 1 sibling, 0 replies; 23+ messages in thread From: Benjamin Marzinski @ 2016-04-28 22:45 UTC (permalink / raw) To: Hannes Reinecke Cc: Peter Volkov, device-mapper development, Xose Vazquez Perez, Zdenek Kabelac On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote: > On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: > > Aside from dropping the socket, it checks that /etc/multipath.conf > > exists, and that the kernel wasn't started with "nompath". Also it runs > > "multipath -A" this reads the kernel commandline from /proc/cmdline, and > > adds any wwids listed as part of any mpath.wwid=<wwid> parameters. > > Hannes NACKed this patch, so the option isn't present upsteam. > > > > > Hmm. Actually, I do like the 'nompath' checking; we do lack the > capability of switching off multipath from the kernel commandline > ATM. So yes, we should be including that bit. > > As for /etc/multipath.conf ... The original setup has been shipping > without any multipath.conf file. So I would be okay with this change > if we can guarantee that /etc/multipath.conf will always be existing. > Seeing that you're running 'multipath -A' to add any wwids, wouldn't > that be sufficient? > IE why do we need the check for /etc/multipath.conf here; couldn't > we make 'multipath -A' return non-zero to avoid multipathd to be > started? The idea with checking for /etc/multipath.conf is exactly that it doesn't ship with one. This way, even if multipath is installed on the system, it isn't automatically enabled. Obviously, simply touching /etc/multipath.conf is enough for a default config. This isn't super necessary in the multipathd.service file, because you need to enable the service for it to run, but I do this to match the checks in the multipath.rules file. All that's involved in this is the check in multipathd.service, the check in multipath.rules, and a small bit of code that gets run when multipath starts, and exits with a warning if you don't have a configuration file. I belive I posted this years ago, and it got Nak'ed. I'm fine if upstream doesn't want to do things this way. multipath -A won't create a configuration file, it will just add any WWIDs from the kernel commandline to the wwids file. I see them as two entirely seperate things. Like I said above, the multipath.rules checks for /etc/multipath.conf as well. You really need the conditions for when multipath is enabled to match between these two files. -Ben > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Teamlead Storage & Networking > hare@suse.de +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 23+ messages in thread
* multipath-tools: irrelevant files 2016-04-27 22:46 ` Benjamin Marzinski 2016-04-28 6:23 ` Hannes Reinecke @ 2016-05-19 15:24 ` Xose Vazquez Perez 2016-06-01 15:05 ` Christophe Varoqui 1 sibling, 1 reply; 23+ messages in thread From: Xose Vazquez Perez @ 2016-05-19 15:24 UTC (permalink / raw) To: Benjamin Marzinski, Hannes Reinecke, Christophe Varoqui, device-mapper development On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: > On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote: >> On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: >>> Btw, are these relevant ? > > For all that I didn't comment on, I feel the same way as Hannes. > >>> getuid/usb_id >> Huh? What is that doing there? >> It should really have been moved to the udev package ... >> >>> kpartx/kpartx_id >>> kpartx/kpartx.rules >> See above. Yes, they are relevant (at least for us) > > Like I said, Red Hat doesn't use them. I'll post our multipath.rules > shortly. > >>> multipath/01_udev >>> multipath/02_multipath >> Not used anymore with systemd/dracut >> >>> multipath/11-dm-mpath.rules >> Yep. Absolutely required. >> >>> multipath.conf.annotated >>> multipath.conf.defaults >>> multipath.conf.synthetic >> Actually, I never saw the need for those. >> Can we at least have them merged? > > I don't think they are being kept up to date anymore. The 'defaults' > information can be gotten from a running system, and it includes the > changes from the config files, so it's much more useful. I have no idea > what people would use 'synthetic' for besides an example of what a > config would look like. And the 'annotated' information is all in the > multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be > happy to see them go. > >>> multipathd/multipathd.init.debian >>> multipathd/multipathd.init.redhat >>> multipathd/multipathd.init.suse >> Old init scripts; doubtful value. >> >>> multipathd/multipathd.service >>> multipathd/multipathd.socket >> systemd service definitions. Yes, required. > > Red Hat has a slightly different multipathd.service file, and we don't > ship the socket file. Since multipathd should always be running, I > don't really see the need. Also, if you start multipathd manually > (instead of through udev) this causes problems with multipathd not > getting messages. > > For those interested, here's a diff of our multipath.service > > diff --git a/multipathd/multipathd.service > b/multipathd/multipathd.service > index d5f8606..1e5dfab 100644 > --- a/multipathd/multipathd.service > +++ b/multipathd/multipathd.service > @@ -2,9 +2,10 @@ > Description=Device-Mapper Multipath Device Controller > Before=iscsi.service iscsid.service lvm2-activation-early.service > Before=local-fs-pre.target > -After=multipathd.socket > +ConditionPathExists=/etc/multipath.conf > +ConditionKernelCommandLine=!nompath > DefaultDependencies=no > -Wants=local-fs-pre.target multipathd.socket blk-availability.service > +Wants=local-fs-pre.target blk-availability.service > Conflicts=shutdown.target > > [Service] > @@ -12,9 +13,9 @@ Type=notify > NotifyAccess=main > LimitCORE=infinity > ExecStartPre=/sbin/modprobe dm-multipath > +ExecStartPre=-/sbin/multipath -A > ExecStart=/sbin/multipathd -d -s > ExecReload=/sbin/multipathd reconfigure > > [Install] > WantedBy=sysinit.target > -Also=multipathd.socket > > > Aside from dropping the socket, it checks that /etc/multipath.conf > exists, and that the kernel wasn't started with "nompath". Also it runs > "multipath -A" this reads the kernel commandline from /proc/cmdline, and > adds any wwids listed as part of any mpath.wwid=<wwid> parameters. > Hannes NACKed this patch, so the option isn't present upsteam. > > >>> multipath/multipath.init.suse >> Old init script; not used anymore. >> >>> multipath/multipath.rules >> Yep. used for udev. >> >>> multipath-tools.spec.in >>> >> Well; due to our buildservice we have to keep a separate spec file >> anyway. So ATM we don't use it. Hi Christophe, more files could be deleted as Benjamin and Hannes have suggested in this thread. I sent also four patches last month, and they're still pending: https://www.redhat.com/archives/dm-devel/2016-April/thread.html#00453 BTW, there are not new tar files at http://christophe.varoqui.free.fr/ , latest is 0.5.0 -thanks- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-tools: irrelevant files 2016-05-19 15:24 ` multipath-tools: irrelevant files Xose Vazquez Perez @ 2016-06-01 15:05 ` Christophe Varoqui 2016-06-04 0:14 ` multipath-tools: web Xose Vazquez Perez 0 siblings, 1 reply; 23+ messages in thread From: Christophe Varoqui @ 2016-06-01 15:05 UTC (permalink / raw) To: Xose Vazquez Perez; +Cc: device-mapper development [-- Attachment #1.1: Type: text/plain, Size: 4702 bytes --] Hi Xose, this 4-patch patchset to janitor the project header files is now merged, and more files deleted (specfile template and suse example sysv init script). Do you care if I don't publish tarballs anymore ? I'd rather deprecate this http://christophe.varoqui.free.fr/ website usage. The gitweb at git.opensvc.com offers the tarball extraction from version tags, for people who don't want to clone the git project. Best regards, Christophe Varoqui OpenSVC On Thu, May 19, 2016 at 5:24 PM, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote: > On 04/28/2016 12:46 AM, Benjamin Marzinski wrote: > > > On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote: > >> On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: > >>> Btw, are these relevant ? > > > > For all that I didn't comment on, I feel the same way as Hannes. > > > >>> getuid/usb_id > >> Huh? What is that doing there? > >> It should really have been moved to the udev package ... > >> > >>> kpartx/kpartx_id > >>> kpartx/kpartx.rules > >> See above. Yes, they are relevant (at least for us) > > > > Like I said, Red Hat doesn't use them. I'll post our multipath.rules > > shortly. > > > >>> multipath/01_udev > >>> multipath/02_multipath > >> Not used anymore with systemd/dracut > >> > >>> multipath/11-dm-mpath.rules > >> Yep. Absolutely required. > >> > >>> multipath.conf.annotated > >>> multipath.conf.defaults > >>> multipath.conf.synthetic > >> Actually, I never saw the need for those. > >> Can we at least have them merged? > > > > I don't think they are being kept up to date anymore. The 'defaults' > > information can be gotten from a running system, and it includes the > > changes from the config files, so it's much more useful. I have no idea > > what people would use 'synthetic' for besides an example of what a > > config would look like. And the 'annotated' information is all in the > > multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be > > happy to see them go. > > > >>> multipathd/multipathd.init.debian > >>> multipathd/multipathd.init.redhat > >>> multipathd/multipathd.init.suse > >> Old init scripts; doubtful value. > >> > >>> multipathd/multipathd.service > >>> multipathd/multipathd.socket > >> systemd service definitions. Yes, required. > > > > Red Hat has a slightly different multipathd.service file, and we don't > > ship the socket file. Since multipathd should always be running, I > > don't really see the need. Also, if you start multipathd manually > > (instead of through udev) this causes problems with multipathd not > > getting messages. > > > > For those interested, here's a diff of our multipath.service > > > > diff --git a/multipathd/multipathd.service > > b/multipathd/multipathd.service > > index d5f8606..1e5dfab 100644 > > --- a/multipathd/multipathd.service > > +++ b/multipathd/multipathd.service > > @@ -2,9 +2,10 @@ > > Description=Device-Mapper Multipath Device Controller > > Before=iscsi.service iscsid.service lvm2-activation-early.service > > Before=local-fs-pre.target > > -After=multipathd.socket > > +ConditionPathExists=/etc/multipath.conf > > +ConditionKernelCommandLine=!nompath > > DefaultDependencies=no > > -Wants=local-fs-pre.target multipathd.socket blk-availability.service > > +Wants=local-fs-pre.target blk-availability.service > > Conflicts=shutdown.target > > > > [Service] > > @@ -12,9 +13,9 @@ Type=notify > > NotifyAccess=main > > LimitCORE=infinity > > ExecStartPre=/sbin/modprobe dm-multipath > > +ExecStartPre=-/sbin/multipath -A > > ExecStart=/sbin/multipathd -d -s > > ExecReload=/sbin/multipathd reconfigure > > > > [Install] > > WantedBy=sysinit.target > > -Also=multipathd.socket > > > > > > Aside from dropping the socket, it checks that /etc/multipath.conf > > exists, and that the kernel wasn't started with "nompath". Also it runs > > "multipath -A" this reads the kernel commandline from /proc/cmdline, and > > adds any wwids listed as part of any mpath.wwid=<wwid> parameters. > > Hannes NACKed this patch, so the option isn't present upsteam. > > > > > >>> multipath/multipath.init.suse > >> Old init script; not used anymore. > >> > >>> multipath/multipath.rules > >> Yep. used for udev. > >> > >>> multipath-tools.spec.in > >>> > >> Well; due to our buildservice we have to keep a separate spec file > >> anyway. So ATM we don't use it. > > Hi Christophe, more files could be deleted as Benjamin and > Hannes have suggested in this thread. > > I sent also four patches last month, and they're still pending: > https://www.redhat.com/archives/dm-devel/2016-April/thread.html#00453 > > > BTW, there are not new tar files at http://christophe.varoqui.free.fr/ , > latest is 0.5.0 > > -thanks- > [-- Attachment #1.2: Type: text/html, Size: 6524 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* multipath-tools: web 2016-06-01 15:05 ` Christophe Varoqui @ 2016-06-04 0:14 ` Xose Vazquez Perez 0 siblings, 0 replies; 23+ messages in thread From: Xose Vazquez Perez @ 2016-06-04 0:14 UTC (permalink / raw) To: Christophe Varoqui; +Cc: device-mapper development On 06/01/2016 05:05 PM, Christophe Varoqui wrote: > Do you care if I don't publish tarballs anymore ? I'd rather deprecate this > http://christophe.varoqui.free.fr/ website usage. The gitweb at git.opensvc.com > <http://git.opensvc.com> offers the tarball extraction from version tags, > for people who don't want to clone the git project. You should add a note to redirect people to gitweb. And replace this message: "Latest release : multipath-tools-0.5.0.tar.bz2" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: multipath-0.5.0 still provides broken udev rules 2016-04-25 10:52 multipath-0.5.0 still provides broken udev rules Peter Volkov 2016-04-25 10:58 ` Zdenek Kabelac @ 2016-04-25 15:04 ` Hannes Reinecke 1 sibling, 0 replies; 23+ messages in thread From: Hannes Reinecke @ 2016-04-25 15:04 UTC (permalink / raw) To: Peter Volkov, dm-devel On 04/25/2016 12:52 PM, Peter Volkov wrote: > Hi, guys. > > There is a problem: udev does not create partitions for multipath > devices in case I use kpartx.rules provided with multipath sources. > I found that udev always go to kpartx_end after following line of rules: > ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end" > > There is 8 (!!!) years old thread that discusses this problem: > https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html > > So what is the current state? Should we fix udev rules for multipath > or should we create better patch for dmsetup.c? Meanwhile I've > copied multipath.rules from redhat and partitions are created as > they should. > > Sigh. I really need to post my multipath update. Stay tuned. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2016-06-04 0:14 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-25 10:52 multipath-0.5.0 still provides broken udev rules Peter Volkov 2016-04-25 10:58 ` Zdenek Kabelac 2016-04-25 12:10 ` Peter Volkov 2016-04-25 12:32 ` Zdenek Kabelac 2016-04-25 12:52 ` Peter Volkov 2016-04-25 12:56 ` Christophe Varoqui 2016-04-25 14:15 ` Peter Volkov 2016-04-25 17:38 ` Benjamin Marzinski 2016-04-26 5:43 ` Hannes Reinecke 2016-04-26 8:39 ` Zdenek Kabelac 2016-04-26 8:47 ` Hannes Reinecke 2016-04-26 9:19 ` Zdenek Kabelac 2016-04-25 20:14 ` Xose Vazquez Perez 2016-04-26 5:53 ` Hannes Reinecke 2016-04-27 22:46 ` Benjamin Marzinski 2016-04-28 6:23 ` Hannes Reinecke 2016-04-28 22:10 ` Benjamin Marzinski 2016-05-11 18:46 ` Distributions mpt code Xose Vazquez Perez 2016-04-28 22:45 ` multipath-0.5.0 still provides broken udev rules Benjamin Marzinski 2016-05-19 15:24 ` multipath-tools: irrelevant files Xose Vazquez Perez 2016-06-01 15:05 ` Christophe Varoqui 2016-06-04 0:14 ` multipath-tools: web Xose Vazquez Perez 2016-04-25 15:04 ` multipath-0.5.0 still provides broken udev rules Hannes Reinecke
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.