On M= on, Apr 25, 2016 at 3:32 PM, Zdenek Kabelac <zkabelac@redhat.com&g= t; wrote:

On 25.4.2016 14:10, P= eter Volkov wrote:

On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com
<mailto:zkabela= c@redhat.com>> wrote:

=C2=A0 =C2=A0 On 25.4.2016 12:52, Peter Volkov wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There is a problem: udev does not create partit= ions for multipath
=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case I use kpartx.rules provided with multipath= sources. I found that udev
=C2=A0 =C2=A0 =C2=A0 =C2=A0 always go to kpartx_end after following line of= rules:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ENV{DM_TABLE_STATE}!=3D"LIVE", GOTO= =3D"kpartx_end"

Actually don't understand what's this table and what's wrong wi= th that. There
is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such<= br> variable in udev rules file that comes with multipath sources:
http://git.opensvc.com/gitweb= .cgi?p=3Dmultipath-tools/.git;a=3Dblob;f=3Dkpartx/kpartx.rules;h=3D022361f9= 07e873ac16fc75459b88af34b27576e5;hb=3DHEAD

So you would need to figure out which rules would have set=C2=A0 DM_TABLE_S= TATE before ?=C2=A0 (I assume such have never existed...)

<= div>

There was a patch suggested for dmsetup:=C2=A0 So it's rather question for upstream kpartx maintainer why these rules<= br> are not maintained in any way.

Yup, =C2= =A0that'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 prepa= res
have this problem.

=C2=A0

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 discussi= ons. Please, correct me if I'm wrong.

Peter.

--001a11444e1ac5d7ab05314ea551-- --===============5113312450388053332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5113312450388053332==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Varoqui Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Mon, 25 Apr 2016 14:56:35 +0200 Message-ID: References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3290065776286608515==" Return-path: In-Reply-To: <571E0E7A.4050703@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Zdenek Kabelac Cc: device-mapper development , Peter Volkov List-Id: dm-devel.ids --===============3290065776286608515== Content-Type: multipart/alternative; boundary=001a113fa5bce9a82e05314eb41f --001a113fa5bce9a82e05314eb41f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9, Peter are you ok with my deleting the udev rules example ? Best regards, On Mon, Apr 25, 2016 at 2:32 PM, Zdenek Kabelac wrote= : > On 25.4.2016 14:10, Peter Volkov wrote: > >> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac > > wrote: >> >> On 25.4.2016 12:52, Peter Volkov wrote: >> >> There is a problem: udev does not create partitions for multipat= h >> 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}!=3D"LIVE", GOTO=3D"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 su= ch >> variable in udev rules file that comes with multipath sources: >> >> http://git.opensvc.com/gitweb.cgi?p=3Dmultipath-tools/.git;a=3Dblob;f=3D= kpartx/kpartx.rules;h=3D022361f907e873ac16fc75459b88af34b27576e5;hb=3DHEAD >> > > > So you would need to figure out which rules would have set DM_TABLE_STAT= E > 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 maintaine= d > in 2009 - that may explain few things as well... > > That's Gentoo. But I think any distro that uses whatever upstream prepare= s >> 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 > --001a113fa5bce9a82e05314eb41f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 ru= leset. Ben, Hannes, Xos=C3=A9, Peter are you ok with my deleting the udev r= ules example ?

Best regards,

<= /div>

On Mon, Apr = 25, 2016 at 2:32 PM, Zdenek Kabelac <zkabelac@redhat.com> = wrote:

On 25.4.2016 14:1= 0, Peter Volkov wrote:

On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com
<mailto:zkabela= c@redhat.com>> wrote:

=C2=A0 =C2=A0 On 25.4.2016 12:52, Peter Volkov wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There is a problem: udev does not create partit= ions for multipath
=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case I use kpartx.rules provided with multipath= sources. I found that udev
=C2=A0 =C2=A0 =C2=A0 =C2=A0 always go to kpartx_end after following line of= rules:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ENV{DM_TABLE_STATE}!=3D"LIVE", GOTO= =3D"kpartx_end"

=C2=A0 =C2=A0 Just curious - what would you want to do with inactive table?= ??

Actually don't understand what's this table and what's wrong wi= th that. There
is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such<= br> variable in udev rules file that comes with multipath sources:
http://git.opensvc.com/gitweb= .cgi?p=3Dmultipath-tools/.git;a=3Dblob;f=3Dkpartx/kpartx.rules;h=3D022361f9= 07e873ac16fc75459b88af34b27576e5;hb=3DHEAD

So you would need to figure out which rules would have set=C2=A0 DM_TABLE_S= TATE before ?=C2=A0 (I assume such have never existed...)

In Fedora/RHEL=C2=A0 these=C2=A0 kpartx.rules are not packaged as they are = likely some 'ancient' rules - IMHO=C2=A0 most of that file is usele= ss on today's distros.
(Unsure about dm-wwn logic???)

So it's rather question for upstream kpartx maintainer why these rules<= br> 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 prepa= res
have this problem.

=C2=A0 =C2=A0 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.co= m
https://www.redhat.com/mailman/listinfo/dm-devel=

--001a113fa5bce9a82e05314eb41f-- --===============3290065776286608515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3290065776286608515==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Volkov Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Mon, 25 Apr 2016 17:15:52 +0300 Message-ID: References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6812695830172173415==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Christophe Varoqui Cc: device-mapper development , Zdenek Kabelac List-Id: dm-devel.ids --===============6812695830172173415== Content-Type: multipart/alternative; boundary=001a11469950934daf05314fd1f5 --001a11469950934daf05314fd1f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9, Peter are you ok with my deleting the udev rules ex= ample > ? > 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. --001a11469950934daf05314fd1f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On M= on, Apr 25, 2016 at 3:56 PM, Christophe Varoqui <christophe.v= aroqui@opensvc.com> wrote:

Distribut= ors can't be asked to agree on a common udev ruleset.

Of course, there is no pressure on downstream distribu= tor on what configuration/udev rules should be used. Yet it's always go= od to have upstream hand for such things. Lot's of packages (lvm/system= d/networkmanager/...) come with an upstream suggested udev rules. Should we= avoid use of that udev rules? I don't think so.

Ben, Hannes, Xos=C3=A9, Peter are you ok with my deleti= ng the udev rules example ?

Since th= ese 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.

--001a11469950934daf05314fd1f5-- --===============6812695830172173415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6812695830172173415==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Mon, 25 Apr 2016 17:04:30 +0200 Message-ID: <571E31FE.5090004@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Peter Volkov , dm-devel@redhat.com List-Id: dm-devel.ids T24gMDQvMjUvMjAxNiAxMjo1MiBQTSwgUGV0ZXIgVm9sa292IHdyb3RlOgo+IEhpLCBndXlzLgo+ IAo+IFRoZXJlIGlzIGEgcHJvYmxlbTogdWRldiBkb2VzIG5vdCBjcmVhdGUgcGFydGl0aW9ucyBm b3IgbXVsdGlwYXRoCj4gZGV2aWNlcyBpbiBjYXNlIEkgdXNlIGtwYXJ0eC5ydWxlcyBwcm92aWRl ZCB3aXRoIG11bHRpcGF0aCBzb3VyY2VzLgo+IEkgZm91bmQgdGhhdCB1ZGV2IGFsd2F5cyBnbyB0 byBrcGFydHhfZW5kIGFmdGVyIGZvbGxvd2luZyBsaW5lIG9mIHJ1bGVzOgo+IEVOVntETV9UQUJM RV9TVEFURX0hPSJMSVZFIiwgR09UTz0ia3BhcnR4X2VuZCIKPiAKPiBUaGVyZSBpcyA4ICghISEp IHllYXJzIG9sZCB0aHJlYWQgdGhhdCBkaXNjdXNzZXMgdGhpcyBwcm9ibGVtOgo+IGh0dHBzOi8v d3d3LnJlZGhhdC5jb20vYXJjaGl2ZXMvZG0tZGV2ZWwvMjAwNy1KdWx5L21zZzAwMDk1Lmh0bWwK PiAKPiBTbyB3aGF0IGlzIHRoZSBjdXJyZW50IHN0YXRlPyBTaG91bGQgd2UgZml4IHVkZXYgcnVs ZXMgZm9yIG11bHRpcGF0aAo+IG9yIHNob3VsZCB3ZSBjcmVhdGUgYmV0dGVyIHBhdGNoIGZvciBk bXNldHVwLmM/IE1lYW53aGlsZSBJJ3ZlCj4gY29waWVkIG11bHRpcGF0aC5ydWxlcyBmcm9tIHJl ZGhhdCBhbmQgcGFydGl0aW9ucyBhcmUgY3JlYXRlZCBhcwo+IHRoZXkgc2hvdWxkLgo+IAo+IApT aWdoLiBJIHJlYWxseSBuZWVkIHRvIHBvc3QgbXkgbXVsdGlwYXRoIHVwZGF0ZS4KU3RheSB0dW5l ZC4KCkNoZWVycywKCkhhbm5lcwotLSAKRHIuIEhhbm5lcyBSZWluZWNrZQkJICAgVGVhbWxlYWQg U3RvcmFnZSAmIE5ldHdvcmtpbmcKaGFyZUBzdXNlLmRlCQkJICAgICAgICAgICAgICAgKzQ5IDkx MSA3NDA1MyA2ODgKU1VTRSBMSU5VWCBHbWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJl cmcKR0Y6IEYuIEltZW5kw7ZyZmZlciwgSi4gU21pdGhhcmQsIEouIEd1aWxkLCBELiBVcG1hbnl1 LCBHLiBOb3J0b24KSFJCIDIxMjg0IChBRyBOw7xybmJlcmcpCgotLQpkbS1kZXZlbCBtYWlsaW5n IGxpc3QKZG0tZGV2ZWxAcmVkaGF0LmNvbQpodHRwczovL3d3dy5yZWRoYXQuY29tL21haWxtYW4v bGlzdGluZm8vZG0tZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Benjamin Marzinski" Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Mon, 25 Apr 2016 12:38:38 -0500 Message-ID: <20160425173838.GE26117@octiron.msp.redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Christophe Varoqui Cc: device-mapper development , Peter Volkov , Zdenek Kabelac List-Id: dm-devel.ids 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=E9, Peter are you ok with my deleting the udev rules examp= le ? 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.co= m> > 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 > > wrote: > = > =A0 =A0 On 25.4.2016 12:52, Peter Volkov wrote: > = > =A0 =A0 =A0 =A0 There is a problem: udev does not create partition= s for > multipath > =A0 =A0 =A0 =A0 devices in > =A0 =A0 =A0 =A0 case I use kpartx.rules provided with multipath so= urces. I > found that udev > =A0 =A0 =A0 =A0 always go to kpartx_end after following line of ru= les: > =A0 =A0 =A0 =A0 ENV{DM_TABLE_STATE}!=3D"LIVE", GOTO=3D"kpartx_end" > = > =A0 =A0 Just curious - what would you want to do with inactive tab= le??? > = > 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=3Dmultipath-tools/.git;a=3D= blob;f=3Dkpartx/kpartx.rules;h=3D022361f907e873ac16fc75459b88af34b27576e5;h= b=3DHEAD > = > So you would need to figure out which rules would have set=A0 > DM_TABLE_STATE before ?=A0 (I assume such have never existed...) > = > In Fedora/RHEL=A0 these=A0 kpartx.rules are not packaged as they are= likely > some 'ancient' rules - IMHO=A0 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 rul= es > 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. > = > =A0 =A0 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 multip= ath, > 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=3Dmultipath-tools/.git;a=3Dblob= ;f=3Dkpartx/kpartx.rules;h=3D022361f907e873ac16fc75459b88af34b27576e5;hb=3D= 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xose Vazquez Perez Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Mon, 25 Apr 2016 22:14:40 +0200 Message-ID: <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Christophe Varoqui , Zdenek Kabelac Cc: device-mapper development , Peter Volkov List-Id: dm-devel.ids T24gMDQvMjUvMjAxNiAwMjo1NiBQTSwgQ2hyaXN0b3BoZSBWYXJvcXVpIHdyb3RlOgoKPiBUaG9z ZSBleGFtcGxlIHVkZXYgcnVsZXMgYXJlIGluZGVlZCB1bm1haW50YWluZWQgYW5kIHNob3VsZCBi ZQo+IHJlbW92ZWQgbm90IHRvIGNvbmZ1c2UgZGlzdHJpYnV0b3JzLgo+IAo+IERpc3RyaWJ1dG9y cyBjYW4ndCBiZSBhc2tlZCB0byBhZ3JlZSBvbiBhIGNvbW1vbiB1ZGV2IHJ1bGVzZXQuCj4gQmVu LCBIYW5uZXMsIFhvc8OpLCBQZXRlciBhcmUgeW91IG9rIHdpdGggbXkgZGVsZXRpbmcgdGhlIHVk ZXYgcnVsZXMgZXhhbXBsZSA/CgpGaW5lIHdpdGggbWUuCgpCdHcsIGFyZSB0aGVzZSByZWxldmFu dCA/CgpnZXR1aWQvdXNiX2lkCmtwYXJ0eC9rcGFydHhfaWQKa3BhcnR4L2twYXJ0eC5ydWxlcwpt dWx0aXBhdGgvMDFfdWRldgptdWx0aXBhdGgvMDJfbXVsdGlwYXRoCm11bHRpcGF0aC8xMS1kbS1t cGF0aC5ydWxlcwptdWx0aXBhdGguY29uZi5hbm5vdGF0ZWQKbXVsdGlwYXRoLmNvbmYuZGVmYXVs dHMKbXVsdGlwYXRoLmNvbmYuc3ludGhldGljCm11bHRpcGF0aGQvbXVsdGlwYXRoZC5pbml0LmRl YmlhbgptdWx0aXBhdGhkL211bHRpcGF0aGQuaW5pdC5yZWRoYXQKbXVsdGlwYXRoZC9tdWx0aXBh dGhkLmluaXQuc3VzZQptdWx0aXBhdGhkL211bHRpcGF0aGQuc2VydmljZQptdWx0aXBhdGhkL211 bHRpcGF0aGQuc29ja2V0Cm11bHRpcGF0aC9tdWx0aXBhdGguaW5pdC5zdXNlCm11bHRpcGF0aC9t dWx0aXBhdGgucnVsZXMKbXVsdGlwYXRoLXRvb2xzLnNwZWMuaW4KCi0tCmRtLWRldmVsIG1haWxp bmcgbGlzdApkbS1kZXZlbEByZWRoYXQuY29tCmh0dHBzOi8vd3d3LnJlZGhhdC5jb20vbWFpbG1h bi9saXN0aW5mby9kbS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Tue, 26 Apr 2016 07:43:37 +0200 Message-ID: <571F0009.3080903@suse.de> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <20160425173838.GE26117@octiron.msp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20160425173838.GE26117@octiron.msp.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com List-Id: dm-devel.ids 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 remove= d not >> to confuse distributors. >> Distributors can't be asked to agree on a common udev ruleset. Ben, >> Hannes, Xos=E9, Peter are you ok with my deleting the udev rules exam= ple ? > = > 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=FCrnberg GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N=FCrnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Tue, 26 Apr 2016 07:53:48 +0200 Message-ID: <571F026C.5040102@suse.de> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Xose Vazquez Perez , Christophe Varoqui , Zdenek Kabelac Cc: device-mapper development , Peter Volkov List-Id: dm-devel.ids T24gMDQvMjUvMjAxNiAxMDoxNCBQTSwgWG9zZSBWYXpxdWV6IFBlcmV6IHdyb3RlOgo+IE9uIDA0 LzI1LzIwMTYgMDI6NTYgUE0sIENocmlzdG9waGUgVmFyb3F1aSB3cm90ZToKPiAKPj4gVGhvc2Ug ZXhhbXBsZSB1ZGV2IHJ1bGVzIGFyZSBpbmRlZWQgdW5tYWludGFpbmVkIGFuZCBzaG91bGQgYmUK Pj4gcmVtb3ZlZCBub3QgdG8gY29uZnVzZSBkaXN0cmlidXRvcnMuCj4+Cj4+IERpc3RyaWJ1dG9y cyBjYW4ndCBiZSBhc2tlZCB0byBhZ3JlZSBvbiBhIGNvbW1vbiB1ZGV2IHJ1bGVzZXQuCj4+IEJl biwgSGFubmVzLCBYb3PDqSwgUGV0ZXIgYXJlIHlvdSBvayB3aXRoIG15IGRlbGV0aW5nIHRoZSB1 ZGV2IHJ1bGVzIGV4YW1wbGUgPwo+IAo+IEZpbmUgd2l0aCBtZS4KPiAKPiBCdHcsIGFyZSB0aGVz ZSByZWxldmFudCA/Cj4gCj4gZ2V0dWlkL3VzYl9pZApIdWg/IFdoYXQgaXMgdGhhdCBkb2luZyB0 aGVyZT8KSXQgc2hvdWxkIHJlYWxseSBoYXZlIGJlZW4gbW92ZWQgdG8gdGhlIHVkZXYgcGFja2Fn ZSAuLi4KCj4ga3BhcnR4L2twYXJ0eF9pZAo+IGtwYXJ0eC9rcGFydHgucnVsZXMKU2VlIGFib3Zl LiBZZXMsIHRoZXkgYXJlIHJlbGV2YW50IChhdCBsZWFzdCBmb3IgdXMpCgo+IG11bHRpcGF0aC8w MV91ZGV2Cj4gbXVsdGlwYXRoLzAyX211bHRpcGF0aApOb3QgdXNlZCBhbnltb3JlIHdpdGggc3lz dGVtZC9kcmFjdXQKCj4gbXVsdGlwYXRoLzExLWRtLW1wYXRoLnJ1bGVzClllcC4gQWJzb2x1dGVs eSByZXF1aXJlZC4KCj4gbXVsdGlwYXRoLmNvbmYuYW5ub3RhdGVkCj4gbXVsdGlwYXRoLmNvbmYu ZGVmYXVsdHMKPiBtdWx0aXBhdGguY29uZi5zeW50aGV0aWMKQWN0dWFsbHksIEkgbmV2ZXIgc2F3 IHRoZSBuZWVkIGZvciB0aG9zZS4KQ2FuIHdlIGF0IGxlYXN0IGhhdmUgdGhlbSBtZXJnZWQ/Cgo+ IG11bHRpcGF0aGQvbXVsdGlwYXRoZC5pbml0LmRlYmlhbgo+IG11bHRpcGF0aGQvbXVsdGlwYXRo ZC5pbml0LnJlZGhhdAo+IG11bHRpcGF0aGQvbXVsdGlwYXRoZC5pbml0LnN1c2UKT2xkIGluaXQg c2NyaXB0czsgZG91YnRmdWwgdmFsdWUuCgo+IG11bHRpcGF0aGQvbXVsdGlwYXRoZC5zZXJ2aWNl Cj4gbXVsdGlwYXRoZC9tdWx0aXBhdGhkLnNvY2tldApzeXN0ZW1kIHNlcnZpY2UgZGVmaW5pdGlv bnMuIFllcywgcmVxdWlyZWQuCgo+IG11bHRpcGF0aC9tdWx0aXBhdGguaW5pdC5zdXNlCk9sZCBp bml0IHNjcmlwdDsgbm90IHVzZWQgYW55bW9yZS4KCj4gbXVsdGlwYXRoL211bHRpcGF0aC5ydWxl cwpZZXAuIHVzZWQgZm9yIHVkZXYuCgo+IG11bHRpcGF0aC10b29scy5zcGVjLmluCj4gCldlbGw7 IGR1ZSB0byBvdXIgYnVpbGRzZXJ2aWNlIHdlIGhhdmUgdG8ga2VlcCBhIHNlcGFyYXRlIHNwZWMg ZmlsZQphbnl3YXkuIFNvIEFUTSB3ZSBkb24ndCB1c2UgaXQuCgpDaGVlcnMsCgpIYW5uZXMKLS0g CkRyLiBIYW5uZXMgUmVpbmVja2UJCSAgIFRlYW1sZWFkIFN0b3JhZ2UgJiBOZXR3b3JraW5nCmhh cmVAc3VzZS5kZQkJCSAgICAgICAgICAgICAgICs0OSA5MTEgNzQwNTMgNjg4ClNVU0UgTElOVVgg R21iSCwgTWF4ZmVsZHN0ci4gNSwgOTA0MDkgTsO8cm5iZXJnCkdGOiBGLiBJbWVuZMO2cmZmZXIs IEouIFNtaXRoYXJkLCBKLiBHdWlsZCwgRC4gVXBtYW55dSwgRy4gTm9ydG9uCkhSQiAyMTI4NCAo QUcgTsO8cm5iZXJnKQoKLS0KZG0tZGV2ZWwgbWFpbGluZyBsaXN0CmRtLWRldmVsQHJlZGhhdC5j b20KaHR0cHM6Ly93d3cucmVkaGF0LmNvbS9tYWlsbWFuL2xpc3RpbmZvL2RtLWRldmVs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zdenek Kabelac Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Tue, 26 Apr 2016 10:39:54 +0200 Message-ID: <571F295A.6060607@redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <20160425173838.GE26117@octiron.msp.redhat.com> <571F0009.3080903@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <571F0009.3080903@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com List-Id: dm-devel.ids 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 remo= ved not >>> to confuse distributors. >>> Distributors can't be asked to agree on a common udev ruleset. Ben, >>> Hannes, Xos=E9, Peter are you ok with my deleting the udev rules ex= ample ? >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Tue, 26 Apr 2016 10:47:56 +0200 Message-ID: <571F2B3C.5040306@suse.de> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <20160425173838.GE26117@octiron.msp.redhat.com> <571F0009.3080903@suse.de> <571F295A.6060607@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <571F295A.6060607@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com List-Id: dm-devel.ids 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=E9, 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=FCrnberg GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N=FCrnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zdenek Kabelac Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Tue, 26 Apr 2016 11:19:33 +0200 Message-ID: <571F32A5.7090405@redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <20160425173838.GE26117@octiron.msp.redhat.com> <571F0009.3080903@suse.de> <571F295A.6060607@redhat.com> <571F2B3C.5040306@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <571F2B3C.5040306@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com, Hannes Reinecke List-Id: dm-devel.ids 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=E9, 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 u= dev = 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Benjamin Marzinski" Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Wed, 27 Apr 2016 17:46:01 -0500 Message-ID: <20160427224601.GG26117@octiron.msp.redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <571F026C.5040102@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Hannes Reinecke Cc: Peter Volkov , device-mapper development , Xose Vazquez Perez , Zdenek Kabelac List-Id: dm-devel.ids 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=E9, 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=3DDevice-Mapper Multipath Device Controller Before=3Discsi.service iscsid.service lvm2-activation-early.service Before=3Dlocal-fs-pre.target -After=3Dmultipathd.socket +ConditionPathExists=3D/etc/multipath.conf +ConditionKernelCommandLine=3D!nompath DefaultDependencies=3Dno -Wants=3Dlocal-fs-pre.target multipathd.socket blk-availability.service +Wants=3Dlocal-fs-pre.target blk-availability.service Conflicts=3Dshutdown.target = [Service] @@ -12,9 +13,9 @@ Type=3Dnotify NotifyAccess=3Dmain LimitCORE=3Dinfinity ExecStartPre=3D/sbin/modprobe dm-multipath +ExecStartPre=3D-/sbin/multipath -A ExecStart=3D/sbin/multipathd -d -s ExecReload=3D/sbin/multipathd reconfigure = [Install] WantedBy=3Dsysinit.target -Also=3Dmultipathd.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=3D 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=FCrnberg > GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG N=FCrnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Thu, 28 Apr 2016 08:23:44 +0200 Message-ID: <5721AC70.3070606@suse.de> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160427224601.GG26117@octiron.msp.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Benjamin Marzinski Cc: Peter Volkov , device-mapper development , Xose Vazquez Perez , Zdenek Kabelac List-Id: dm-devel.ids T24gMDQvMjgvMjAxNiAxMjo0NiBBTSwgQmVuamFtaW4gTWFyemluc2tpIHdyb3RlOgo+IE9uIFR1 ZSwgQXByIDI2LCAyMDE2IGF0IDA3OjUzOjQ4QU0gKzAyMDAsIEhhbm5lcyBSZWluZWNrZSB3cm90 ZToKPj4gT24gMDQvMjUvMjAxNiAxMDoxNCBQTSwgWG9zZSBWYXpxdWV6IFBlcmV6IHdyb3RlOgo+ Pj4gT24gMDQvMjUvMjAxNiAwMjo1NiBQTSwgQ2hyaXN0b3BoZSBWYXJvcXVpIHdyb3RlOgo+Pj4K Pj4+PiBUaG9zZSBleGFtcGxlIHVkZXYgcnVsZXMgYXJlIGluZGVlZCB1bm1haW50YWluZWQgYW5k IHNob3VsZCBiZQo+Pj4+IHJlbW92ZWQgbm90IHRvIGNvbmZ1c2UgZGlzdHJpYnV0b3JzLgo+Pj4+ Cj4+Pj4gRGlzdHJpYnV0b3JzIGNhbid0IGJlIGFza2VkIHRvIGFncmVlIG9uIGEgY29tbW9uIHVk ZXYgcnVsZXNldC4KPj4+PiBCZW4sIEhhbm5lcywgWG9zw6ksIFBldGVyIGFyZSB5b3Ugb2sgd2l0 aCBteSBkZWxldGluZyB0aGUgdWRldiBydWxlcyBleGFtcGxlID8KPj4+Cj4+PiBGaW5lIHdpdGgg bWUuCj4+Pgo+Pj4gQnR3LCBhcmUgdGhlc2UgcmVsZXZhbnQgPwo+IAo+IEZvciBhbGwgdGhhdCBJ IGRpZG4ndCBjb21tZW50IG9uLCBJIGZlZWwgdGhlIHNhbWUgd2F5IGFzIEhhbm5lcy4KPiAKPj4+ IGdldHVpZC91c2JfaWQKPj4gSHVoPyBXaGF0IGlzIHRoYXQgZG9pbmcgdGhlcmU/Cj4+IEl0IHNo b3VsZCByZWFsbHkgaGF2ZSBiZWVuIG1vdmVkIHRvIHRoZSB1ZGV2IHBhY2thZ2UgLi4uCj4+Cj4+ PiBrcGFydHgva3BhcnR4X2lkCj4+PiBrcGFydHgva3BhcnR4LnJ1bGVzCj4+IFNlZSBhYm92ZS4g WWVzLCB0aGV5IGFyZSByZWxldmFudCAoYXQgbGVhc3QgZm9yIHVzKQo+IAo+IExpa2UgSSBzYWlk LCBSZWQgSGF0IGRvZXNuJ3QgdXNlIHRoZW0uIEknbGwgcG9zdCBvdXIgbXVsdGlwYXRoLnJ1bGVz Cj4gc2hvcnRseS4KPiAKV2hpY2ggd291bGQgYmUgY29vbC4KSSB3YXMgYWN0dWFsbHkgaG9waW5n IHRvIG1lZXQgeW91IGluIFJhbGVpZ2ggbGFzdCB3ZWVrLCBidXQgdGhlbiBpdApkaWRuJ3Qgd29y ayBvdXQuCgo+Pj4gbXVsdGlwYXRoLzAxX3VkZXYKPj4+IG11bHRpcGF0aC8wMl9tdWx0aXBhdGgK Pj4gTm90IHVzZWQgYW55bW9yZSB3aXRoIHN5c3RlbWQvZHJhY3V0Cj4+Cj4+PiBtdWx0aXBhdGgv MTEtZG0tbXBhdGgucnVsZXMKPj4gWWVwLiBBYnNvbHV0ZWx5IHJlcXVpcmVkLgo+Pgo+Pj4gbXVs dGlwYXRoLmNvbmYuYW5ub3RhdGVkCj4+PiBtdWx0aXBhdGguY29uZi5kZWZhdWx0cwo+Pj4gbXVs dGlwYXRoLmNvbmYuc3ludGhldGljCj4+IEFjdHVhbGx5LCBJIG5ldmVyIHNhdyB0aGUgbmVlZCBm b3IgdGhvc2UuCj4+IENhbiB3ZSBhdCBsZWFzdCBoYXZlIHRoZW0gbWVyZ2VkPwo+IAo+IEkgZG9u J3QgdGhpbmsgdGhleSBhcmUgYmVpbmcga2VwdCB1cCB0byBkYXRlIGFueW1vcmUuICBUaGUgJ2Rl ZmF1bHRzJwo+IGluZm9ybWF0aW9uIGNhbiBiZSBnb3R0ZW4gZnJvbSBhIHJ1bm5pbmcgc3lzdGVt LCBhbmQgaXQgaW5jbHVkZXMgdGhlCj4gY2hhbmdlcyBmcm9tIHRoZSBjb25maWcgZmlsZXMsIHNv IGl0J3MgbXVjaCBtb3JlIHVzZWZ1bC4gSSBoYXZlIG5vIGlkZWEKPiB3aGF0IHBlb3BsZSB3b3Vs ZCB1c2UgJ3N5bnRoZXRpYycgZm9yIGJlc2lkZXMgYW4gZXhhbXBsZSBvZiB3aGF0IGEKPiBjb25m aWcgd291bGQgbG9vayBsaWtlLiBBbmQgdGhlICdhbm5vdGF0ZWQnIGluZm9ybWF0aW9uIGlzIGFs bCBpbiB0aGUKPiBtdWx0aXBhdGguY29uZiBtYW5wYWdlLiBSZWQgSGF0IGRvZXNuJ3Qgc2hpcCB0 aGVzZSBmaWxlcyBhbnltb3JlLiBJJ2QgYmUKPiBoYXBweSB0byBzZWUgdGhlbSBnby4KPiAgCkNv dWxkbid0IGFncmVlIG1vcmUuCkxldCdzIGRyb3AgdGhlbS4KCj4+PiBtdWx0aXBhdGhkL211bHRp cGF0aGQuaW5pdC5kZWJpYW4KPj4+IG11bHRpcGF0aGQvbXVsdGlwYXRoZC5pbml0LnJlZGhhdAo+ Pj4gbXVsdGlwYXRoZC9tdWx0aXBhdGhkLmluaXQuc3VzZQo+PiBPbGQgaW5pdCBzY3JpcHRzOyBk b3VidGZ1bCB2YWx1ZS4KPj4KPj4+IG11bHRpcGF0aGQvbXVsdGlwYXRoZC5zZXJ2aWNlCj4+PiBt dWx0aXBhdGhkL211bHRpcGF0aGQuc29ja2V0Cj4+IHN5c3RlbWQgc2VydmljZSBkZWZpbml0aW9u cy4gWWVzLCByZXF1aXJlZC4KPiAKPiBSZWQgSGF0IGhhcyBhIHNsaWdodGx5IGRpZmZlcmVudCBt dWx0aXBhdGhkLnNlcnZpY2UgZmlsZSwgYW5kIHdlIGRvbid0Cj4gc2hpcCB0aGUgc29ja2V0IGZp bGUuICBTaW5jZSBtdWx0aXBhdGhkIHNob3VsZCBhbHdheXMgYmUgcnVubmluZywgSQo+IGRvbid0 IHJlYWxseSBzZWUgdGhlIG5lZWQuIEFsc28sIGlmIHlvdSBzdGFydCBtdWx0aXBhdGhkIG1hbnVh bGx5Cj4gKGluc3RlYWQgb2YgdGhyb3VnaCB1ZGV2KSB0aGlzIGNhdXNlcyBwcm9ibGVtcyB3aXRo IG11bHRpcGF0aGQgbm90Cj4gZ2V0dGluZyBtZXNzYWdlcy4KPiAKSG1tLiBBY3R1YWxseSwgSSBx dWl0ZSBsaWtlIHRoZSBzeXN0ZW1kIGludGVncmF0aW9uOyBpdCBhbGxvd3MgbWUgdG8Kc2lnbmFs IHRoZSBpbnRlcm5hbCBtdWx0aXBhdGhkIHN0YXRlIGJhY2sgdG8gc3lzdGVtZDoKCiMgc3lzdGVt Y3RsIHN0YXR1cyBtdWx0aXBhdGhkCm11bHRpcGF0aGQuc2VydmljZSAtIERldmljZS1NYXBwZXIg TXVsdGlwYXRoIERldmljZSBDb250cm9sbGVyCiAgIExvYWRlZDogbG9hZGVkICgvdXNyL2xpYi9z eXN0ZW1kL3N5c3RlbS9tdWx0aXBhdGhkLnNlcnZpY2U7IGVuYWJsZWQpCiAgIEFjdGl2ZTogYWN0 aXZlIChydW5uaW5nKSBzaW5jZSBXZWQgMjAxNi0wNC0yNyAxMjozOTo1OSBDRVNUOyAxOWggYWdv CiBNYWluIFBJRDogNjkxMyAobXVsdGlwYXRoZCkKICAgU3RhdHVzOiAiaWRsZSIKICAgQ0dyb3Vw OiAvc3lzdGVtLnNsaWNlL211bHRpcGF0aGQuc2VydmljZQogICAgICAgICAgIOKUlOKUgDY5MTMg L3NiaW4vbXVsdGlwYXRoZCAtZCAtcwoKV2hpY2ggSSBmaW5kIHF1aXRlIG5lYXQuIEFuZCBJIGd1 ZXNzIHdlIHNob3VsZCBiZSBhYmxlIHRvIG92ZXJjb21lCnRoZSBtYW51YWxseSBzdGFydGVkIGlz c3VlIGJ5IGNoZWNraW5nIGlmIHRoZSBzb2NrZXQgaXMgcHJlc2VudCwgYW5kCmp1c3QgZXhlY3V0 ZSBhICdyZWNvbmZpZ3VyZScgY29tbWFuZCBpZiBzby4KTGV0IG1lIHNlZSAuLi4KCj4gRm9yIHRo b3NlIGludGVyZXN0ZWQsIGhlcmUncyBhIGRpZmYgb2Ygb3VyIG11bHRpcGF0aC5zZXJ2aWNlCj4g Cj4gZGlmZiAtLWdpdCBhL211bHRpcGF0aGQvbXVsdGlwYXRoZC5zZXJ2aWNlCj4gYi9tdWx0aXBh dGhkL211bHRpcGF0aGQuc2VydmljZQo+IGluZGV4IGQ1Zjg2MDYuLjFlNWRmYWIgMTAwNjQ0Cj4g LS0tIGEvbXVsdGlwYXRoZC9tdWx0aXBhdGhkLnNlcnZpY2UKPiArKysgYi9tdWx0aXBhdGhkL211 bHRpcGF0aGQuc2VydmljZQo+IEBAIC0yLDkgKzIsMTAgQEAKPiAgRGVzY3JpcHRpb249RGV2aWNl LU1hcHBlciBNdWx0aXBhdGggRGV2aWNlIENvbnRyb2xsZXIKPiAgQmVmb3JlPWlzY3NpLnNlcnZp Y2UgaXNjc2lkLnNlcnZpY2UgbHZtMi1hY3RpdmF0aW9uLWVhcmx5LnNlcnZpY2UKPiAgQmVmb3Jl PWxvY2FsLWZzLXByZS50YXJnZXQKPiAtQWZ0ZXI9bXVsdGlwYXRoZC5zb2NrZXQKPiArQ29uZGl0 aW9uUGF0aEV4aXN0cz0vZXRjL211bHRpcGF0aC5jb25mCj4gK0NvbmRpdGlvbktlcm5lbENvbW1h bmRMaW5lPSFub21wYXRoCj4gIERlZmF1bHREZXBlbmRlbmNpZXM9bm8KPiAtV2FudHM9bG9jYWwt ZnMtcHJlLnRhcmdldCBtdWx0aXBhdGhkLnNvY2tldCBibGstYXZhaWxhYmlsaXR5LnNlcnZpY2UK PiArV2FudHM9bG9jYWwtZnMtcHJlLnRhcmdldCBibGstYXZhaWxhYmlsaXR5LnNlcnZpY2UKPiAg Q29uZmxpY3RzPXNodXRkb3duLnRhcmdldAo+ICAKPiAgW1NlcnZpY2VdCj4gQEAgLTEyLDkgKzEz LDkgQEAgVHlwZT1ub3RpZnkKPiAgTm90aWZ5QWNjZXNzPW1haW4KPiAgTGltaXRDT1JFPWluZmlu aXR5Cj4gIEV4ZWNTdGFydFByZT0vc2Jpbi9tb2Rwcm9iZSBkbS1tdWx0aXBhdGgKPiArRXhlY1N0 YXJ0UHJlPS0vc2Jpbi9tdWx0aXBhdGggLUEKPiAgRXhlY1N0YXJ0PS9zYmluL211bHRpcGF0aGQg LWQgLXMKPiAgRXhlY1JlbG9hZD0vc2Jpbi9tdWx0aXBhdGhkIHJlY29uZmlndXJlCj4gIAo+ICBb SW5zdGFsbF0KPiAgV2FudGVkQnk9c3lzaW5pdC50YXJnZXQKPiAtQWxzbz1tdWx0aXBhdGhkLnNv Y2tldAo+IAo+IAo+IEFzaWRlIGZyb20gZHJvcHBpbmcgdGhlIHNvY2tldCwgaXQgY2hlY2tzIHRo YXQgL2V0Yy9tdWx0aXBhdGguY29uZgo+IGV4aXN0cywgYW5kIHRoYXQgdGhlIGtlcm5lbCB3YXNu J3Qgc3RhcnRlZCB3aXRoICJub21wYXRoIi4gQWxzbyBpdCBydW5zCj4gIm11bHRpcGF0aCAtQSIg dGhpcyByZWFkcyB0aGUga2VybmVsIGNvbW1hbmRsaW5lIGZyb20gL3Byb2MvY21kbGluZSwgYW5k Cj4gYWRkcyBhbnkgd3dpZHMgbGlzdGVkIGFzIHBhcnQgb2YgYW55IG1wYXRoLnd3aWQ9PHd3aWQ+ IHBhcmFtZXRlcnMuCj4gSGFubmVzIE5BQ0tlZCB0aGlzIHBhdGNoLCBzbyB0aGUgb3B0aW9uIGlz bid0IHByZXNlbnQgdXBzdGVhbS4KPiAKPiAgCkhtbS4gQWN0dWFsbHksIEkgZG8gbGlrZSB0aGUg J25vbXBhdGgnIGNoZWNraW5nOyB3ZSBkbyBsYWNrIHRoZQpjYXBhYmlsaXR5IG9mIHN3aXRjaGlu ZyBvZmYgbXVsdGlwYXRoIGZyb20gdGhlIGtlcm5lbCBjb21tYW5kbGluZQpBVE0uIFNvIHllcywg d2Ugc2hvdWxkIGJlIGluY2x1ZGluZyB0aGF0IGJpdC4KCkFzIGZvciAvZXRjL211bHRpcGF0aC5j b25mIC4uLiBUaGUgb3JpZ2luYWwgc2V0dXAgaGFzIGJlZW4gc2hpcHBpbmcKd2l0aG91dCBhbnkg bXVsdGlwYXRoLmNvbmYgZmlsZS4gU28gSSB3b3VsZCBiZSBva2F5IHdpdGggdGhpcyBjaGFuZ2UK aWYgd2UgY2FuIGd1YXJhbnRlZSB0aGF0IC9ldGMvbXVsdGlwYXRoLmNvbmYgd2lsbCBhbHdheXMg YmUgZXhpc3RpbmcuClNlZWluZyB0aGF0IHlvdSdyZSBydW5uaW5nICdtdWx0aXBhdGggLUEnIHRv IGFkZCBhbnkgd3dpZHMsIHdvdWxkbid0CnRoYXQgYmUgc3VmZmljaWVudD8KSUUgd2h5IGRvIHdl IG5lZWQgdGhlIGNoZWNrIGZvciAvZXRjL211bHRpcGF0aC5jb25mIGhlcmU7IGNvdWxkbid0Cndl IG1ha2UgJ211bHRpcGF0aCAtQScgcmV0dXJuIG5vbi16ZXJvIHRvIGF2b2lkIG11bHRpcGF0aGQg dG8gYmUKc3RhcnRlZD8KCkNoZWVycywKCkhhbm5lcwotLSAKRHIuIEhhbm5lcyBSZWluZWNrZQkJ ICAgVGVhbWxlYWQgU3RvcmFnZSAmIE5ldHdvcmtpbmcKaGFyZUBzdXNlLmRlCQkJICAgICAgICAg ICAgICAgKzQ5IDkxMSA3NDA1MyA2ODgKU1VTRSBMSU5VWCBHbWJILCBNYXhmZWxkc3RyLiA1LCA5 MDQwOSBOw7xybmJlcmcKR0Y6IEYuIEltZW5kw7ZyZmZlciwgSi4gU21pdGhhcmQsIEouIEd1aWxk LCBELiBVcG1hbnl1LCBHLiBOb3J0b24KSFJCIDIxMjg0IChBRyBOw7xybmJlcmcpCgotLQpkbS1k ZXZlbCBtYWlsaW5nIGxpc3QKZG0tZGV2ZWxAcmVkaGF0LmNvbQpodHRwczovL3d3dy5yZWRoYXQu Y29tL21haWxtYW4vbGlzdGluZm8vZG0tZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Benjamin Marzinski" Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Thu, 28 Apr 2016 17:10:45 -0500 Message-ID: <20160428221045.GH26117@octiron.msp.redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> <5721AC70.3070606@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5721AC70.3070606@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Hannes Reinecke Cc: Peter Volkov , device-mapper development , Xose Vazquez Perez , Zdenek Kabelac List-Id: dm-devel.ids 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" From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Benjamin Marzinski" Subject: Re: multipath-0.5.0 still provides broken udev rules Date: Thu, 28 Apr 2016 17:45:20 -0500 Message-ID: <20160428224520.GI26117@octiron.msp.redhat.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> <5721AC70.3070606@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <5721AC70.3070606@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Hannes Reinecke Cc: Peter Volkov , device-mapper development , Xose Vazquez Perez , Zdenek Kabelac List-Id: dm-devel.ids 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=3D 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=FCrnberg > GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG N=FCrnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xose Vazquez Perez Subject: Distributions mpt code Date: Wed, 11 May 2016 20:46:23 +0200 Message-ID: References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> <5721AC70.3070606@suse.de> <20160428221045.GH26117@octiron.msp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160428221045.GH26117@octiron.msp.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development Cc: Ritesh Raj Sarraf List-Id: dm-devel.ids 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xose Vazquez Perez Subject: multipath-tools: irrelevant files Date: Thu, 19 May 2016 17:24:18 +0200 Message-ID: References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160427224601.GG26117@octiron.msp.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Benjamin Marzinski , Hannes Reinecke , Christophe Varoqui , device-mapper development List-Id: dm-devel.ids 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= 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- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Varoqui Subject: Re: multipath-tools: irrelevant files Date: Wed, 1 Jun 2016 17:05:21 +0200 Message-ID: References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7993392951212017678==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Xose Vazquez Perez Cc: device-mapper development List-Id: dm-devel.ids --===============7993392951212017678== Content-Type: multipart/alternative; boundary=001a1142100a82da79053438d159 --001a1142100a82da79053438d159 Content-Type: text/plain; charset=UTF-8 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 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= 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- > --001a1142100a82da79053438d159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Xose,

this 4-patch patchset to janit= or the project header files is now merged, and more files deleted (specfile= template and suse example sysv init script).

Do y= ou care if I don't publish tarballs anymore ? I'd rather deprecate = this=C2=A0http://christophe.varoqui.fre= e.fr/=C2=A0=C2=A0website usage.= The gitweb at git.opensvc.com offer= s the tarball extraction from version tags, for people who don't want t= o clone the git project.

Best regards,

C= hristophe Varoqui

OpenSVC

<= br>

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.=C2=A0 The &#= 39;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 wh= at 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&#= 39;t
> ship the socket file.=C2=A0 Since multipathd should always be running,= I
> don't really see the need. Also, if you start multipathd manually<= br> > (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 @@
>=C2=A0 Description=3DDevice-Mapper Multipath Device Controller
>=C2=A0 Before=3Discsi.service iscsid.service lvm2-activation-early.serv= ice
>=C2=A0 Before=3Dlocal-fs-pre.target
> -After=3Dmultipathd.socket
> +ConditionPathExists=3D/etc/multipath.conf
> +ConditionKernelCommandLine=3D!nompath
>=C2=A0 DefaultDependencies=3Dno
> -Wants=3Dlocal-fs-pre.target multipathd.socket blk-availability.servic= e
> +Wants=3Dlocal-fs-pre.target blk-availability.service
>=C2=A0 Conflicts=3Dshutdown.target
>
>=C2=A0 [Service]
> @@ -12,9 +13,9 @@ Type=3Dnotify
>=C2=A0 NotifyAccess=3Dmain
>=C2=A0 LimitCORE=3Dinfinity
>=C2=A0 ExecStartPre=3D/sbin/modprobe dm-multipath
> +ExecStartPre=3D-/sbin/multipath -A
>=C2=A0 ExecStart=3D/sbin/multipathd -d -s
>=C2=A0 ExecReload=3D/sbin/multipathd reconfigure
>
>=C2=A0 [Install]
>=C2=A0 WantedBy=3Dsysinit.target
> -Also=3Dmultipathd.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=3D<wwid> paramet= ers.
> 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-

--001a1142100a82da79053438d159-- --===============7993392951212017678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7993392951212017678==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xose Vazquez Perez Subject: multipath-tools: web Date: Sat, 4 Jun 2016 02:14:09 +0200 Message-ID: <488773fe-65eb-23c7-00d1-029170f0a64c@gmail.com> References: <571DF852.6030604@redhat.com> <571E0E7A.4050703@redhat.com> <1986ca6b-d281-4faf-2b50-11c3dc132463@gmail.com> <571F026C.5040102@suse.de> <20160427224601.GG26117@octiron.msp.redhat.com>

Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Christophe Varoqui Cc: device-mapper development List-Id: dm-devel.ids 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 > 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"