Re: [dm-devel] [PATCHv2 0/7] multipathd 'cookie' handling rework

2016-05-09 Thread Benjamin Marzinski
On Mon, May 09, 2016 at 12:52:58PM +0200, Hannes Reinecke wrote: > Hi all, > > here's now the second attempt to fixup the 'cookie' handling > in multipath-tools. > I've removed the patch to pass in a cookie as an argument > for dm_addmap_reload() and dm_simplecmd(). > And I've removed all

Re: [dm-devel] [PATCH 4/7] devmapper: wait for udev in dm_simplecmd_noflush()

2016-05-09 Thread Benjamin Marzinski
On Mon, May 09, 2016 at 12:53:02PM +0200, Hannes Reinecke wrote: > When calling dm_simplecmd_noflush() with udev_flags set we > need to set the 'need_sync' flag otherwise the udev flags > will never be set. The other possibility here would be to temporarily disable udev sync support, and then

Re: [dm-devel] md: md.c: fix oops in mddev_suspend for raid0

2016-05-09 Thread Mike Snitzer
On Mon, May 09 2016 at 11:50am -0400, hei...@redhat.com wrote: > From: Heinz Mauelshagen > > Introduced by upstream commit 70d9798b95562abac005d4ba71d28820f9a201eb > > The raid0 personality does not create mddev->thread as oposed to > other personalities

[dm-devel] [PATCH] md: raid5: add prerequisite to run underneath dm-raid

2016-05-09 Thread heinzm
From: Heinz Mauelshagen In case md runs underneath the dm-raid target, the mddev does not have a request queue or gendisk, thus avoid accesses. This patch adds a missing conditional to the raid5 personality. Signed-of-by: Heinz Mauelshagen ---

[dm-devel] [PATCH] md: raid10: add prerequisite to run underneath dm-raid

2016-05-09 Thread heinzm
From: Heinz Mauelshagen In case md runs underneath the dm-raid target, the mddev does not have a request queue or gendisk, thus avoid accesses to it. This patch adds two missing conditionals to the raid10 personality. Signed-of-by: Heinz Mauelshagen ---

Re: [dm-devel] [PATCH 4/6] libmultipath: Fixup 'DM_DEVICE_RELOAD' handling

2016-05-09 Thread Benjamin Marzinski
On Mon, May 09, 2016 at 12:26:36PM +0200, Hannes Reinecke wrote: > On 05/06/2016 10:12 PM, Benjamin Marzinski wrote: > > On Wed, May 04, 2016 at 07:57:28AM +0200, Hannes Reinecke wrote: > >> libdevmapper has the 'quirk' that DM_DEVICE_CREATE is translated > >> internally into a create/load/resume

[dm-devel] [PATCH 2/7] devmapper: do not call dm_udev_complete if dm_task_set_cookie() failed

2016-05-09 Thread Hannes Reinecke
As per Benjamin Marzinski libdevice-mapper will take care of cleaning up the cookie for us. So there's no need to call dm_udev_complete() if dm_task_set_cookie() fails. Signed-off-by: Hannes Reinecke --- libmultipath/devmapper.c | 10 -- 1 file changed, 4 insertions(+), 6

[dm-devel] [PATCH 4/7] devmapper: wait for udev in dm_simplecmd_noflush()

2016-05-09 Thread Hannes Reinecke
When calling dm_simplecmd_noflush() with udev_flags set we need to set the 'need_sync' flag otherwise the udev flags will never be set. Signed-off-by: Hannes Reinecke --- libmultipath/configure.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[dm-devel] [PATCH 7/7] libmultipath: Fixup 'DM_DEVICE_RELOAD' handling

2016-05-09 Thread Hannes Reinecke
libdevmapper has the 'quirk' that DM_DEVICE_CREATE is translated internally into a create/load/resume sequence, and the associated cookie will wait for the last 'resume' to complete. However, DM_DEVICE_RELOAD has no such translation, so if there is a cookie assigned to it the caller _cannot_ wait

[dm-devel] [PATCH 1/7] devmapper: do not flush I/O for DM_DEVICE_CREATE

2016-05-09 Thread Hannes Reinecke
DM_DEVICE_CREATE loads a new table, so there cannot be any I/O pending. Hence we should be setting the 'no flush' and 'skip lockfs' flag to avoid delays during creation. Signed-off-by: Hannes Reinecke --- libmultipath/devmapper.c | 25 - 1 file changed, 16

Re: [dm-devel] [PATCH 4/6] libmultipath: Fixup 'DM_DEVICE_RELOAD' handling

2016-05-09 Thread Hannes Reinecke
On 05/06/2016 10:12 PM, Benjamin Marzinski wrote: > On Wed, May 04, 2016 at 07:57:28AM +0200, Hannes Reinecke wrote: >> libdevmapper has the 'quirk' that DM_DEVICE_CREATE is translated >> internally into a create/load/resume sequence, and the associated >> cookie will wait for the last 'resume' to