Re: [dm-devel] [PATCH 55/57] multipathd: asynchronous configuration

On Wed, Apr 27, 2016 at 01:10:56PM +0200, Hannes Reinecke wrote: > For initial configuration multipathd waits until it has synchronized > with the existing setup. On larger systems this takes up quite > some time (I've measured 80 seconds on a system with 1024 paths) > causing systemd to stall and

Re: [dm-devel] [PATCH 55/57] multipathd: asynchronous configuration

On Wed, Apr 27, 2016 at 01:10:56PM +0200, Hannes Reinecke wrote: Oh, I did have one other thought. If you're not changing the signal mask in uevent_listen, can't you just use poll? Otherwise people are going to try and figure out what's going on with the signals that they're missing (at least

Re: [dm-devel] [PATCH 22/57] multipath: use option '-i' when called from udev

Ben, does this patch actually break the Red Hat integration ? I'm inclined to merge it if not. Thanks, Christophe On Tue, May 3, 2016 at 7:44 AM, Hannes Reinecke wrote: > On 05/02/2016 05:31 PM, Benjamin Marzinski wrote: > > On Wed, Apr 27, 2016 at 01:10:23PM +0200, Hannes

Re: [dm-devel] [PATCH 28/57] libmultipath: use a shared lock to co-operate with udev

On 05/02/2016 06:26 PM, Benjamin Marzinski wrote: > On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote: >> udev since v214 is placing a shared lock on the device node >> whenever it's processing the event. This introduces a race >> condition with multipathd, as multipathd is

Re: [dm-devel] [PATCH 30/57] multipathd: skip uninitialized devices during reconfiguration

On 05/02/2016 09:14 PM, Benjamin Marzinski wrote: > On Wed, Apr 27, 2016 at 01:10:31PM +0200, Hannes Reinecke wrote: >> libudev has a separate filter setting to skip uninitialized >> devices during enumeration. > > So, I assume if udev filters out a device here, it's because a uevent > should be

Re: [dm-devel] [PATCH 19/57] multipathd: Do not print misleading message 'not found in pathvec'

The patch was merged as-is, so reinstating the warning, using another non-conflicting phrasing, would require a new patch. On Tue, May 3, 2016 at 7:47 AM, Hannes Reinecke wrote: > On 05/02/2016 05:40 PM, Benjamin Marzinski wrote: > > On Wed, Apr 27, 2016 at 01:10:20PM +0200,

Re: [dm-devel] [PATCH 36/57] libmultipath: pass in 'cookie' as argument for dm_addmap()

On 05/03/2016 12:23 AM, Benjamin Marzinski wrote: > On Wed, Apr 27, 2016 at 01:10:37PM +0200, Hannes Reinecke wrote: >> Instead of generating the cookie internally we should be >> passing in the cookie to dm_addmap(). > > These look like they could actually cause problems. With > dm_addmap_create

[dm-devel] [PATCH] Revert 'multipathd: Do not print misleading message "not found in pathvec"'

As discussed on the mailing list the logging messages should remain, so revert the patch, increase the logging level and update the message itself to be more instructive. Signed-off-by: Hannes Reinecke --- libmultipath/structs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [dm-devel] [PATCH 56/57] multipathd: push down lock in checkerloop()

On Wed, Apr 27, 2016 at 01:10:57PM +0200, Hannes Reinecke wrote: > Instead of grabbing the lock at the start of the checkerloop > and releasing it at the end we should be holding it only > during the time when we actually need it. I'm pretty sure that this can cause crashes if multipathd

Re: [dm-devel] [PATCH 28/57] libmultipath: use a shared lock to co-operate with udev

On Tue, May 03, 2016 at 04:31:19PM +0100, Germano Percossi wrote: > Hi, > > Sorry for jumping in the middle of patch review > > On 05/03/2016 03:27 PM, Benjamin Marzinski wrote: > >On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote: > >>On 05/02/2016 06:26 PM, Benjamin Marzinski

Re: [dm-devel] [PATCH 00/42] v7: separate operations from flags in the bio/request structs

mchri...@redhat.com writes: > The following patches begin to cleanup the request->cmd_flags and > bio->bi_rw mess. We currently use cmd_flags to specify the operation, > attributes and state of the request. For bi_rw we use it for similar > info and also the priority but then also have another

Re: [dm-devel] [PATCH 36/57] libmultipath: pass in 'cookie' as argument for dm_addmap()

On Tue, May 03, 2016 at 11:31:19AM +0200, Hannes Reinecke wrote: > On 05/03/2016 12:23 AM, Benjamin Marzinski wrote: > > On Wed, Apr 27, 2016 at 01:10:37PM +0200, Hannes Reinecke wrote: > >> Instead of generating the cookie internally we should be > >> passing in the cookie to dm_addmap(). > > >

Re: [dm-devel] [PATCH 36/57] libmultipath: pass in 'cookie' as argument for dm_addmap()

On Tue, May 03, 2016 at 04:43:01PM +0200, Hannes Reinecke wrote: > On 05/03/2016 04:39 PM, Benjamin Marzinski wrote: > > On Tue, May 03, 2016 at 11:31:19AM +0200, Hannes Reinecke wrote: > >> On 05/03/2016 12:23 AM, Benjamin Marzinski wrote: > >>> On Wed, Apr 27, 2016 at 01:10:37PM +0200, Hannes

Re: [dm-devel] [PATCH 28/57] libmultipath: use a shared lock to co-operate with udev

On Tue, May 03, 2016 at 09:27:32AM -0500, Benjamin Marzinski wrote: > I don't see why this same issue can't happen for anyone creating any > type of dm device build out of multiple physical devices, and AFAIK, lvm > doesn't bother to protect users against this, even though it can now >

Re: [dm-devel] [PATCH 36/57] libmultipath: pass in 'cookie' as argument for dm_addmap()

On 05/03/2016 04:39 PM, Benjamin Marzinski wrote: > On Tue, May 03, 2016 at 11:31:19AM +0200, Hannes Reinecke wrote: >> On 05/03/2016 12:23 AM, Benjamin Marzinski wrote: >>> On Wed, Apr 27, 2016 at 01:10:37PM +0200, Hannes Reinecke wrote: Instead of generating the cookie internally we should

Re: [dm-devel] [PATCH 28/57] libmultipath: use a shared lock to co-operate with udev

On Tue, May 03, 2016 at 09:27:32AM -0500, Benjamin Marzinski wrote: > On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote: > > On 05/02/2016 06:26 PM, Benjamin Marzinski wrote: > > > On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote: > > >> udev since v214 is placing a

Re: [dm-devel] [PATCH 22/57] multipath: use option '-i' when called from udev

On 05/03/2016 04:14 PM, Benjamin Marzinski wrote: > On Tue, May 03, 2016 at 08:37:08AM +0200, Christophe Varoqui wrote: >>Ben, >>does this patch actually break the Red Hat integration ? >>I'm inclined to merge it if not. > > Like we talked about earlier, RedHat uses a completely

Re: [dm-devel] [PATCH 56/57] multipathd: push down lock in checkerloop()

On Tue, May 03, 2016 at 05:17:34PM -0500, Benjamin Marzinski wrote: > On Wed, Apr 27, 2016 at 01:10:57PM +0200, Hannes Reinecke wrote: > > Instead of grabbing the lock at the start of the checkerloop > > and releasing it at the end we should be holding it only > > during the time when we actually

Re: [dm-devel] [PATCH 28/57] libmultipath: use a shared lock to co-operate with udev

Hi, Sorry for jumping in the middle of patch review On 05/03/2016 03:27 PM, Benjamin Marzinski wrote: On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote: On 05/02/2016 06:26 PM, Benjamin Marzinski wrote: On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote: This is

Re: [dm-devel] [PATCH 22/57] multipath: use option '-i' when called from udev

On Tue, May 03, 2016 at 08:37:08AM +0200, Christophe Varoqui wrote: >Ben, >does this patch actually break the Red Hat integration ? >I'm inclined to merge it if not. Like we talked about earlier, RedHat uses a completely different multipath.rules file, which includes some command

Re: [dm-devel] [PATCH 53/57] multipathd: implement 'show map $map format $fmt'

On Wed, Apr 27, 2016 at 01:10:54PM +0200, Hannes Reinecke wrote: > Similar to the existing 'show map $map topology', but allowing > formatted content. This touches on a patch I've thought about writing, but never got around to. The issue is that with show_maps_topology() we call