Re: [dm-devel] [PATCH 0/1] add option to output JSON for multipathd command

On 05/04/2016 07:22 PM, Alasdair G Kergon wrote: > On Wed, May 04, 2016 at 04:23:47PM -0400, Todd Gill wrote: >> I had earlier sent an email to dm-devel proposing we add a feature >> in multipathd to output multipath map topology in JSON format. This >> patch contains to the code for that feature.

Re: [dm-devel] [PATCH 0/1] add option to output JSON for multipathd command

On 05/04/16 13:23, Todd Gill wrote: I had earlier sent an email to dm-devel proposing we add a feature in multipathd to output multipath map topology in JSON format. This patch contains to the code for that feature. Having an option for the CLI to output in JSON would allow higher level

Re: [dm-devel] [PATCH 0/1] add option to output JSON for multipathd command

On Wed, May 04, 2016 at 04:23:47PM -0400, Todd Gill wrote: > I had earlier sent an email to dm-devel proposing we add a feature > in multipathd to output multipath map topology in JSON format. This > patch contains to the code for that feature. > Having an option for the CLI to output in JSON

[dm-devel] [PATCH 1/1] add display of map information in JSON format

The patch adds these commands: multipathd show maps json multipathd show map $map json Each command will output the requested map(s) in JSON. For the "show maps json" command, the patch pre-allocates INITIAL_REPLY_LEN * 5. The JSON text is about 5x the size of the "show maps topology" text.

[dm-devel] [PATCH 0/1] add option to output JSON for multipathd command

Hi, I had earlier sent an email to dm-devel proposing we add a feature in multipathd to output multipath map topology in JSON format. This patch contains to the code for that feature. Having an option for the CLI to output in JSON would allow higher level applications to more easily

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

Mike Christie writes: > On 05/03/2016 03:44 PM, Jeff Moyer wrote: >> Hi, Mike, >> >> That git tree doesn't seem to exist. I did manage to apply your patch >> set on top of next-20160415, though. >> >> So... what testing did you do? ;-) I ran into the following problems >

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

On 05/03/2016 03:44 PM, Jeff Moyer wrote: > 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

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

On 05/03/2016 08:25 PM, Benjamin Marzinski wrote: > 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

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

On 05/04/2016 01:24 AM, Benjamin Marzinski wrote: > 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

[dm-devel] [PATCH 2/6] libmultipath: pass in 'cookie' as argument for dm_addmap()

Instead of generating the cookie internally we should be passing in the cookie to dm_addmap(). Signed-off-by: Hannes Reinecke --- libmultipath/devmapper.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/libmultipath/devmapper.c

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

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 6/6] libmultipath: fixup dm_rename to complete cookie on failure

>From my understanding we should be calling udev_complete() on a cookie if dm_task_set_cookie() failed. Signed-off-by: Hannes Reinecke --- libmultipath/devmapper.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libmultipath/devmapper.c