* reinstate path not working
@ 2015-05-18 8:39 Tejaswini Poluri
2015-05-18 16:27 ` Benjamin Marzinski
0 siblings, 1 reply; 11+ messages in thread
From: Tejaswini Poluri @ 2015-05-18 8:39 UTC (permalink / raw)
To: device-mapper development; +Cc: Christophe Varoqui
[-- Attachment #1.1: Type: text/plain, Size: 790 bytes --]
Hii,
We are trying to test multipath setup in our target and tried the various
commands of multipathd demaon and we find the following error:
root@x86-generic-64:~# multipathd -k"fail path sdc"; multipathd
-k'reinstate path
sdc'; multipathd -k"show paths";
[ 3962.708523] device-mapper: multipath: Failing path 8:32.
ok
ok
hcil dev dev_t pri dm_st chk_st next_check
4:0:0:1 sdc 8:32 1 [active][faulty] .......... 1/20 <<<=== CHECK
5:0:0:1 sdd 8:48 1 [active][ready] XX........ 4/20
sdc path becomes [active][ready] only after the polling interval but not
immediately after the reinstate path command.
I am observing this in latest multipath tools in ubuntu machine as well.
Please let me know if its a known issue or if I am doing something wrong.
Regards.
Tejaswini
[-- Attachment #1.2: Type: text/html, Size: 2259 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-05-18 8:39 reinstate path not working Tejaswini Poluri
@ 2015-05-18 16:27 ` Benjamin Marzinski
[not found] ` <CAH=b03t3QGuHM_x-eQTGZRkpYsAmOT4yMRCPQhp-smWM6ZXRhw@mail.gmail.com>
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Marzinski @ 2015-05-18 16:27 UTC (permalink / raw)
To: device-mapper development
On Mon, May 18, 2015 at 02:09:27PM +0530, Tejaswini Poluri wrote:
> Hii,
> We are trying to test multipath setup in our target and tried the various
> commands of multipathd demaon and we find the following error:
> root@x86-generic-64:~# multipathd -k"fail path sdc"; multipathd
> -k'reinstate path
> sdc'; multipathd -k"show paths";
> [ 3962.708523] device-mapper: multipath: Failing path 8:32.
> ok
> ok
> hcil dev dev_t pri dm_st chk_st next_check
> 4:0:0:1 sdc 8:32 1 [active][faulty] .......... 1/20 <<<=== CHECK
> 5:0:0:1 sdd 8:48 1 [active][ready] XX........ 4/20
> sdc path becomes [active][ready] only after the polling interval but not
> immediately after the reinstate path command.
> I am observing this in latest multipath tools in ubuntu machine as well.
> Please let me know if its a known issue or if I am doing something wrong.
> Regards.
> Tejaswini
the reinstate command is supposed to reinstate the device with the
kernel, and it does that. The checker state doesn't change until the
next time that the path is checked. I agree that it's odd that the
check state switches to faulty as soon as you fail the path, but it
doesn't switch back until the next check after you reinistate it.
The issue is that multipathd needs to override the checker output,
so that a failed path won't be immeditately reinstated. Once the
path comes back, multipathd wants to record the switch in the checker
thread, so that it can refresh path information what wasn't
automatically done when the path was reinstated. However, it may make
more sense to have a different checker state for when the device is
in the failed state, so that it's obvious that the checker state is
being overruled.
-Ben
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
[not found] ` <20150611205149.GA1409@octiron.msp.redhat.com>
@ 2015-06-23 10:18 ` Tejaswini Poluri
2015-06-25 23:02 ` Benjamin Marzinski
0 siblings, 1 reply; 11+ messages in thread
From: Tejaswini Poluri @ 2015-06-23 10:18 UTC (permalink / raw)
To: Benjamin Marzinski, device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 14504 bytes --]
Hi Ben,
This is regarding the add map issue I have been discussing. Posting the
issue again to remind.
*Case 1 : remove and add map.*
root@x86-generic-64:~# multipathd -k'show maps'
name sysfs uuid
dmpath0 dm-0 1IET_00010001
root@x86-generic-64:~# multipathd -k'remove map dmpath0'
ok
root@x86-generic-64:~# multipathd -k'show maps'
root@x86-generic-64:~# multipathd -k'add map dmpath0'
ok
root@x86-generic-64:~# multipathd -k'show maps'
root@x86-generic-64:~#
Once a map is removed, we are able to add it only using #multipath command
and not using multipathd tools.
I have fixed the problem with two approaches. I would like you to review
the same.
*Patch1* : By making 'remove map dmpath0' to remove only the map and not
the device. I have added extra functions discard_map and dm_remove_map so
as to not interfere with the existing code.
*Patch 2*: The approach you have suggested.By getting wwid from the mapname
and doing coalesce_paths. I have just moved the following code in
ev_add_map to cli_add_map.
r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
if (refwwid) {
r = coalesce_paths(vecs, NULL, refwwid,0);
dm_lib_release();
}
changed dev to param.
I have tested the same in all 3 versions -0.4.8, 0.4.9 and 0.5.0. It would
be great if you can review the same so that it doesn't cause any extra side
effects.
I guess Patch2 is the way u have suggested me in the previous mail. Please
review it and share your views.
Regards,
Tejaswini
On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski <bmarzins@redhat.com>
wrote:
> On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri wrote:
> >
> > > We are testing multipathd tools with all the possible options
> and the
> > > following fails.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> #multipath
> > > command and not using multipathd tools.
> >
> > It is working the way it was designed, but possibly it would make
> sense
> > to change the design.
> >
> > You have mentioned that it would make sense to change the design to
> add
> > map. Are there plans to change the design ?
> > I am trying to understand the code flow to change the design. Can you
> > guide me if we should stop removing the device from in the remove map
> code
> > flow or start adding the device and the map in the add map code flow.
> >
> > have tried to understand the remove map code flow of multipathd in
> 0.4.8
> > code.
>
> I think that we want multipath to actually remove the map (instead of
> just not monitoring it) when you call "remove map <map>". We just want
> "add map <map>" to try to create the map if it doesn't exist. To do
> that, you would need to first firgure out what WWID is associated with
> <map>. Presumably, <map> could either be an alias, wwid, or even the
> name of a path in the map. Once you found the map, you would have to
> call the code to create the map.
>
> Also, to answer your IRC question, no the 0.4.8 code is not still being
> developed upstream. All upstream patches only go against the current
> head. There are no other upstream branches.
>
> -Ben
> >
> > ev_remove_map (char * devname, struct vectors * vecs)
> >
> > flush_map(mpp, vecs);
> >
> > dm_flush_map(mpp->alias, DEFAULT_TARGET);
> >
> > if (!dm_map_present(mapname))
> >
> > return 0;
> >
> > if (dm_type(mapname, type) <= 0)
> >
> > return 1;
> >
> > if (dm_remove_partmaps(mapname))
> >
> > return 1;
> >
> > if (dm_get_opencount(mapname)) {
> >
> > condlog(2, "%s: map in use", mapname);
> >
> > return 1;
> >
> > }
> >
> > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> >
> > if (r) {
> >
> > condlog(4, "multipath map %s removed", mapname);
> >
> > return 0;
> >
> > }
> >
> >
> >
> > orphan_paths(vecs->pathvec, mpp);
> >
> > remove_map(mpp, vecs, stop_waiter_thread, 1);
> >
> > Is removing this below line, the right step to stop removing the
> device ?
> > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> >
> > Regards,
> >
> > Tejaswini
> >
> > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > <[1]tejaswinipoluri3@gmail.com> wrote:
> >
> > Thanks a lot Ben for the quick and detailed reply. I have been
> > struggling to understand and conclude the issues with multipath as
> I am
> > the only one working from my team. Your inputs help me a lot. Thanks
> > again.
> > Regards,
> > Tejaswini
> > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > <[2]bmarzins@redhat.com> wrote:
> >
> > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini Poluri wrote:
> > > Hii Ben,
> > >
> > > We are testing multipathd tools with all the possible
> options and
> > the
> > > following fails.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> > #multipath
> > > command and not using multipathd tools.
> >
> > It is working the way it was designed, but possibly it would make
> > sense
> > to change the design. The "remove map" command, not only stops
> > multipathd from monitoring the multipath device, but it removes it
> > from
> > the system as well. The "add map" command makes multipath
> monitor an
> > already existing multipath device that in wasn't previously
> > monitoring.
> > These commands do this for historical reasons. multipathd wasn't
> > originally in charge of creating multipath devices, multipath
> was.
> > Once
> > it had created the device, it ran
> >
> > multipathd -k"add map <MAP>"
> >
> > to make multipathd start monitoring it. However things haven't
> worked
> > this way since RHEL4, so possibly "add map" should actually
> create the
> > device if it doesn't currently exist.
> > > Case 2 : Active paths test case
> > > # while true ; do sleep 3 ; multipathd -k'remove path sdb' ;
> > multipathd
> > > -k'add path sdb' ; multipathd -k'show maps status' ; done
> > > ok
> > > ok
> > > name failback queueing paths dm-st
> > > dmpath0 - - 1 active // It should be 2.
> >
> > This is simply a timing issue. What you are seeing it the number
> of
> > active paths. These are paths that the kernel can use. The "add
> path"
> > command doesn't update the kernel state. This happens later in
> > response
> > to the kernel reloading the device table. So, in a second or two,
> this
> > will say 2, as expected.
> >
> > > We would like to know if the test cases are valid and if
> these
> > are bugs or
> > > any design issues.
> > >
> > > Case 3 : Fail path and reinstate path
> > > root@x86-generic-64:~# multipathd -k"fail path sdc";
> multipathd
> > > -k'reinstate path sdc'; multipathd -k"show paths";
> > > > [ 3962.708523] device-mapper: multipath: Failing path
> 8:32.
> > > > ok
> > > > ok
> > > > hcil dev dev_t pri dm_st chk_st next_check
> > > > 4:0:0:1 sdc 8:32 1 [active][faulty] .......... 1/20
> > <==CHECK
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........ 4/20
> > > sdc path becomes [active][ready] only after the polling
> interval
> > but not
> > > immediately after the reinstate path command.
> > > You have answered that this is a design issue. But we have
> heard
> > from our
> > > test team that the same test case works in RHEL6. Did you
> observe
> > it?
> > > I am also finding that the test cases fail because we are
> trying
> > to do
> > > multiple commands at one shot. Please share your thoughts so
> > that it
> > > could help me in debugging the issues further.
> > >
> >
> > It's totally possible that the checker state is immediately
> updated in
> > RHEL6. Like I said before, what it currently does, although
> correct,
> > is confusing, and perhaps we need a different checker state for
> paths
> > where the "fail path" command has been used.
> >
> > -Ben
> > > Regards,
> > > Tejaswini
> > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini Poluri
> > > <[1][3]tejaswinipoluri3@gmail.com> wrote:
> > >
> > > Thanks a lot Ben. I will look into it more.
> > > On Mon, May 18, 2015 at 9:57 PM, Benjamin Marzinski
> > > <[2][4]bmarzins@redhat.com> wrote:
> > >
> > > On Mon, May 18, 2015 at 02:09:27PM +0530, Tejaswini
> Poluri
> > wrote:
> > > > Hii,
> > > > We are trying to test multipath setup in our target
> and
> > tried the
> > > various
> > > > commands of multipathd demaon and we find the
> following
> > error:
> > > > root@x86-generic-64:~# multipathd -k"fail path
> sdc";
> > multipathd
> > > > -k'reinstate path
> > > > sdc'; multipathd -k"show paths";
> > > > [ 3962.708523] device-mapper: multipath: Failing
> > path 8:32.
> > > > ok
> > > > ok
> > > > hcil dev dev_t pri dm_st chk_st next_check
> > > > 4:0:0:1 sdc 8:32 1 [active][faulty] ..........
> 1/20
> > <<<===
> > > CHECK
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........
> 4/20
> > > > sdc path becomes [active][ready] only after the
> polling
> > interval
> > > but not
> > > > immediately after the reinstate path command.
> > > > I am observing this in latest multipath tools in
> ubuntu
> > machine
> > > as well.
> > > > Please let me know if its a known issue or if I am
> doing
> > > something wrong.
> > > > Regards.
> > > > Tejaswini
> > >
> > > the reinstate command is supposed to reinstate the device
> > with the
> > > kernel, and it does that. The checker state doesn't
> change
> > until the
> > > next time that the path is checked. I agree that it's
> odd
> > that the
> > > check state switches to faulty as soon as you fail the
> path,
> > but it
> > > doesn't switch back until the next check after you
> reinistate
> > it.
> > >
> > > The issue is that multipathd needs to override the
> checker
> > output,
> > > so that a failed path won't be immeditately reinstated.
> Once
> > the
> > > path comes back, multipathd wants to record the switch
> in the
> > checker
> > > thread, so that it can refresh path information what
> wasn't
> > > automatically done when the path was reinstated.
> However, it
> > may make
> > > more sense to have a different checker state for when the
> > device is
> > > in the failed state, so that it's obvious that the
> checker
> > state is
> > > being overruled.
> > >
> > > -Ben
> > >
> > > > --
> > > > dm-devel mailing list
> > > > [3][5]dm-devel@redhat.com
> > > > [4][6]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > --
> > > dm-devel mailing list
> > > [5][7]dm-devel@redhat.com
> > > [6][8]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[9]tejaswinipoluri3@gmail.com
> > > 2. mailto:[10]bmarzins@redhat.com
> > > 3. mailto:[11]dm-devel@redhat.com
> > > 4. [12]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 5. mailto:[13]dm-devel@redhat.com
> > > 6. [14]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:tejaswinipoluri3@gmail.com
> > 2. mailto:bmarzins@redhat.com
> > 3. mailto:tejaswinipoluri3@gmail.com
> > 4. mailto:bmarzins@redhat.com
> > 5. mailto:dm-devel@redhat.com
> > 6. https://www.redhat.com/mailman/listinfo/dm-devel
> > 7. mailto:dm-devel@redhat.com
> > 8. https://www.redhat.com/mailman/listinfo/dm-devel
> > 9. mailto:tejaswinipoluri3@gmail.com
> > 10. mailto:bmarzins@redhat.com
> > 11. mailto:dm-devel@redhat.com
> > 12. https://www.redhat.com/mailman/listinfo/dm-devel
> > 13. mailto:dm-devel@redhat.com
> > 14. https://www.redhat.com/mailman/listinfo/dm-devel
>
[-- Attachment #1.2: Type: text/html, Size: 21449 bytes --]
[-- Attachment #2: 0.4.8_add_map_patch1 --]
[-- Type: application/octet-stream, Size: 2760 bytes --]
diff -rup multipath-tool_0.4.8.orig/libmultipath/devmapper.c multipath-tool_0.4.8_add_map/libmultipath/devmapper.c
--- multipath-tool_0.4.8.orig/libmultipath/devmapper.c 2015-06-16 12:41:45.513994000 +0530
+++ multipath-tool_0.4.8_add_map/libmultipath/devmapper.c 2015-06-18 13:00:40.321060152 +0530
@@ -503,6 +503,27 @@ dm_flush_map (char * mapname, char * typ
}
extern int
+dm_remove_map (char * mapname, char * type)
+{
+ condlog(2, "%s",__func__);
+ if (!dm_map_present(mapname))
+ return 0;
+
+ if (dm_type(mapname, type) <= 0)
+ return 1;
+
+ if (dm_remove_partmaps(mapname))
+ return 1;
+
+ if (dm_get_opencount(mapname)) {
+ condlog(2, "%s: map in use", mapname);
+ return 1;
+ }
+ condlog(4, "multipath map %s removed", mapname);
+ return 0;
+}
+
+extern int
dm_flush_maps (char * type)
{
int r = 0;
diff -rup multipath-tool_0.4.8.orig/libmultipath/devmapper.h multipath-tool_0.4.8_add_map/libmultipath/devmapper.h
--- multipath-tool_0.4.8.orig/libmultipath/devmapper.h 2015-05-12 17:50:48.488293000 +0530
+++ multipath-tool_0.4.8_add_map/libmultipath/devmapper.h 2015-06-18 11:48:41.908950878 +0530
@@ -8,6 +8,7 @@ int dm_get_map(char *, unsigned long lon
int dm_get_status(char *, char *);
int dm_type(char *, char *);
int dm_flush_map (char *, char *);
+int dm_remove_map (char *, char *);
int dm_flush_maps (char *);
int dm_fail_path(char * mapname, char * path);
int dm_reinstate_path(char * mapname, char * path);
diff -rup multipath-tool_0.4.8.orig/multipathd/main.c multipath-tool_0.4.8_add_map/multipathd/main.c
--- multipath-tool_0.4.8.orig/multipathd/main.c 2015-05-12 17:50:48.496293000 +0530
+++ multipath-tool_0.4.8_add_map/multipathd/main.c 2015-06-18 13:11:03.917075932 +0530
@@ -175,7 +175,31 @@ sync_maps_state(vector mpvec)
vector_foreach_slot (mpvec, mpp, i)
sync_map_state(mpp);
}
+static int
+discard_map(struct multipath * mpp, struct vectors * vecs)
+{
+ /*
+ * clear references to this map before flushing so we can ignore
+ * the spurious uevent we may generate with the dm_flush_map call below
+ */
+ if (dm_remove_map(mpp->alias, DEFAULT_TARGET)) {
+ /*
+ * May not really be an error -- if the map was already flushed
+ * from the device mapper by dmsetup(8) for instance.
+ */
+ condlog(0, "%s: can't flush", mpp->alias);
+ return 1;
+ }
+ else {
+ dm_lib_release();
+ condlog(3, "%s: devmap removed", mpp->alias);
+ }
+ orphan_paths(vecs->pathvec, mpp);
+ remove_map(mpp, vecs, stop_waiter_thread, 1);
+
+ return 0;
+}
static int
flush_map(struct multipath * mpp, struct vectors * vecs)
{
@@ -294,7 +318,8 @@ ev_remove_map (char * devname, struct ve
devname);
return 0;
}
- flush_map(mpp, vecs);
+ //flush_map(mpp, vecs);
+ discard_map(mpp, vecs);
return 0;
}
[-- Attachment #3: 0.5.0_add_map_patch2 --]
[-- Type: application/octet-stream, Size: 959 bytes --]
diff --git a/multipathd/cli_handlers.c b/multipathd/cli_handlers.c
index dc96c45..b53fe03 100644
--- a/multipathd/cli_handlers.c
+++ b/multipathd/cli_handlers.c
@@ -537,7 +537,7 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
char dev_path[PATH_SIZE];
char *alias;
int rc;
-
+ char *refwwid;
param = convert_dev(param, 0);
condlog(2, "%s: add map (operator)", param);
@@ -547,6 +547,14 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
condlog(2, "%s: map blacklisted", param);
return 0;
}
+ rc = get_refwwid(param, DEV_DEVMAP, vecs->pathvec, &refwwid);
+
+ if (refwwid) {
+ condlog(2, "%s: add map (operator)", refwwid);
+ if(coalesce_paths(vecs, NULL, refwwid, 0))
+ condlog(2, "%s: coalesce-paths failed", param);
+ dm_lib_release();
+ }
minor = dm_get_minor(param);
if (minor < 0) {
condlog(2, "%s: not a device mapper table", param);
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-06-23 10:18 ` Tejaswini Poluri
@ 2015-06-25 23:02 ` Benjamin Marzinski
2015-06-26 6:51 ` Tejaswini Poluri
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Marzinski @ 2015-06-25 23:02 UTC (permalink / raw)
To: Tejaswini Poluri; +Cc: device-mapper development
On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:
> Hi Ben,
>
> This is regarding the add map issue I have been discussing. Posting the
> issue again to remind.
>
> Case 1 : remove and add map.
> root@x86-generic-64:~# multipathd -k'show maps'
> name sysfs uuid
> dmpath0 dm-0 1IET_00010001
> root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> ok
> root@x86-generic-64:~# multipathd -k'show maps'
> root@x86-generic-64:~# multipathd -k'add map dmpath0'
> ok
> root@x86-generic-64:~# multipathd -k'show maps'
> root@x86-generic-64:~#
> Once a map is removed, we are able to add it only using #multipath
> command and not using multipathd tools.
>
> I have fixed the problem with two approaches. I would like you to review
> the same.
> Patch1 : By making 'remove map dmpath0' to remove only the map and not the
> device. I have added extra functions discard_map and dm_remove_map so as
> to not interfere with the existing code.
>
> Patch 2: The approach you have suggested.By getting wwid from the mapname
> and doing coalesce_paths. I have just moved the following code in
> ev_add_map to cli_add_map.
This is the general idea we'd like to go with. However, looking at the
latest upstream code, I don't think you should pull code in from
ev_add_map() to cli_add_map() like your patch does. cli_add_map()
already calls ev_add_map(), and ev_add_map() is certainly able to add
the map if it doesn't already exist.
You would just need to call it with
ev_add_map(param, NULL, vecs);
and ev_add_map() will happily create you a new multipath device. All
you need to do is make sure that all the functions that ev_add_map()
calls with alias can accept a NULL value there.
This might not be the best way to go about this, however. It turns out
that right now, even though ev_add_map() technically has the ability to
create new maps, nothing currently uses it, and it really doesn't make
sense for it to be there. Instead of just copying that code, you could
pull the map creation code out of ev_add_map() and add it to
cli_add_map(), for those situations where the requested device doesn't
already exist.
But having the code in both cli_add_map() and ev_add_map() when one
already calls the other doesn't seem necessary.
-Ben
>
> r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
>
> if (refwwid) {
> r = coalesce_paths(vecs, NULL, refwwid,0);
> dm_lib_release();
> }
>
> changed dev to param.
>
> I have tested the same in all 3 versions -0.4.8, 0.4.9 and 0.5.0. It would
> be great if you can review the same so that it doesn't cause any extra
> side effects.
> I guess Patch2 is the way u have suggested me in the previous mail. Please
> review it and share your views.
> Regards,
> Tejaswini
> On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> <[1]bmarzins@redhat.com> wrote:
>
> On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri wrote:
> >
> > > We are testing multipathd tools with all the possible options
> and the
> > > following fails.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> #multipath
> > > command and not using multipathd tools.
> >
> > It is working the way it was designed, but possibly it would make
> sense
> > to change the design.
> >
> > You have mentioned that it would make sense to change the design to
> add
> > map. Are there plans to change the design ?
> > I am trying to understand the code flow to change the design. Can
> you
> > guide me if we should stop removing the device from in the remove
> map code
> > flow or start adding the device and the map in the add map code
> flow.
> >
> > have tried to understand the remove map code flow of multipathd in
> 0.4.8
> > code.
>
> I think that we want multipath to actually remove the map (instead of
> just not monitoring it) when you call "remove map <map>". We just want
> "add map <map>" to try to create the map if it doesn't exist. To do
> that, you would need to first firgure out what WWID is associated with
> <map>. Presumably, <map> could either be an alias, wwid, or even the
> name of a path in the map. Once you found the map, you would have to
> call the code to create the map.
>
> Also, to answer your IRC question, no the 0.4.8 code is not still being
> developed upstream. All upstream patches only go against the current
> head. There are no other upstream branches.
>
> -Ben
> >
> > ev_remove_map (char * devname, struct vectors * vecs)
> >
> > flush_map(mpp, vecs);
> >
> > dm_flush_map(mpp->alias, DEFAULT_TARGET);
> >
> > if (!dm_map_present(mapname))
> >
> > return 0;
> >
> > if (dm_type(mapname, type) <= 0)
> >
> > return 1;
> >
> > if (dm_remove_partmaps(mapname))
> >
> > return 1;
> >
> > if (dm_get_opencount(mapname)) {
> >
> > condlog(2, "%s: map in use", mapname);
> >
> > return 1;
> >
> > }
> >
> > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> >
> > if (r) {
> >
> > condlog(4, "multipath map %s removed", mapname);
> >
> > return 0;
> >
> > }
> >
> >
> >
> > orphan_paths(vecs->pathvec, mpp);
> >
> > remove_map(mpp, vecs, stop_waiter_thread,
> 1);
> >
> > Is removing this below line, the right step to stop removing the
> device ?
> > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> >
> > Regards,
> >
> > Tejaswini
> >
> > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > <[1][2]tejaswinipoluri3@gmail.com> wrote:
> >
> > Thanks a lot Ben for the quick and detailed reply. I have been
> > struggling to understand and conclude the issues with multipath
> as I am
> > the only one working from my team. Your inputs help me a lot.
> Thanks
> > again.
> > Regards,
> > Tejaswini
> > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > <[2][3]bmarzins@redhat.com> wrote:
> >
> > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini Poluri
> wrote:
> > > Hii Ben,
> > >
> > > We are testing multipathd tools with all the possible
> options and
> > the
> > > following fails.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> > #multipath
> > > command and not using multipathd tools.
> >
> > It is working the way it was designed, but possibly it would
> make
> > sense
> > to change the design. The "remove map" command, not only stops
> > multipathd from monitoring the multipath device, but it removes
> it
> > from
> > the system as well. The "add map" command makes multipath
> monitor an
> > already existing multipath device that in wasn't previously
> > monitoring.
> > These commands do this for historical reasons. multipathd
> wasn't
> > originally in charge of creating multipath devices, multipath
> was.
> > Once
> > it had created the device, it ran
> >
> > multipathd -k"add map <MAP>"
> >
> > to make multipathd start monitoring it. However things haven't
> worked
> > this way since RHEL4, so possibly "add map" should actually
> create the
> > device if it doesn't currently exist.
> > > Case 2 : Active paths test case
> > > # while true ; do sleep 3 ; multipathd -k'remove path sdb'
> ;
> > multipathd
> > > -k'add path sdb' ; multipathd -k'show maps status' ; done
> > > ok
> > > ok
> > > name failback queueing paths dm-st
> > > dmpath0 - - 1 active // It should be 2.
> >
> > This is simply a timing issue. What you are seeing it the
> number of
> > active paths. These are paths that the kernel can use. The
> "add path"
> > command doesn't update the kernel state. This happens later in
> > response
> > to the kernel reloading the device table. So, in a second or
> two, this
> > will say 2, as expected.
> >
> > > We would like to know if the test cases are valid and if
> these
> > are bugs or
> > > any design issues.
> > >
> > > Case 3 : Fail path and reinstate path
> > > root@x86-generic-64:~# multipathd -k"fail path sdc";
> multipathd
> > > -k'reinstate path sdc'; multipathd -k"show paths";
> > > > [ 3962.708523] device-mapper: multipath: Failing path
> 8:32.
> > > > ok
> > > > ok
> > > > hcil dev dev_t pri dm_st chk_st next_check
> > > > 4:0:0:1 sdc 8:32 1 [active][faulty] ..........
> 1/20
> > <==CHECK
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........
> 4/20
> > > sdc path becomes [active][ready] only after the polling
> interval
> > but not
> > > immediately after the reinstate path command.
> > > You have answered that this is a design issue. But we have
> heard
> > from our
> > > test team that the same test case works in RHEL6. Did you
> observe
> > it?
> > > I am also finding that the test cases fail because we are
> trying
> > to do
> > > multiple commands at one shot. Please share your thoughts
> so
> > that it
> > > could help me in debugging the issues further.
> > >
> >
> > It's totally possible that the checker state is immediately
> updated in
> > RHEL6. Like I said before, what it currently does, although
> correct,
> > is confusing, and perhaps we need a different checker state for
> paths
> > where the "fail path" command has been used.
> >
> > -Ben
> > > Regards,
> > > Tejaswini
> > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini Poluri
> > > <[1][3][4]tejaswinipoluri3@gmail.com> wrote:
> > >
> > > Thanks a lot Ben. I will look into it more.
> > > On Mon, May 18, 2015 at 9:57 PM, Benjamin Marzinski
> > > <[2][4][5]bmarzins@redhat.com> wrote:
> > >
> > > On Mon, May 18, 2015 at 02:09:27PM +0530, Tejaswini
> Poluri
> > wrote:
> > > > Hii,
> > > > We are trying to test multipath setup in our
> target and
> > tried the
> > > various
> > > > commands of multipathd demaon and we find the
> following
> > error:
> > > > root@x86-generic-64:~# multipathd -k"fail path
> sdc";
> > multipathd
> > > > -k'reinstate path
> > > > sdc'; multipathd -k"show paths";
> > > > [ 3962.708523] device-mapper: multipath: Failing
> > path 8:32.
> > > > ok
> > > > ok
> > > > hcil dev dev_t pri dm_st chk_st next_check
> > > > 4:0:0:1 sdc 8:32 1 [active][faulty] ..........
> 1/20
> > <<<===
> > > CHECK
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........
> 4/20
> > > > sdc path becomes [active][ready] only after the
> polling
> > interval
> > > but not
> > > > immediately after the reinstate path command.
> > > > I am observing this in latest multipath tools in
> ubuntu
> > machine
> > > as well.
> > > > Please let me know if its a known issue or if I
> am doing
> > > something wrong.
> > > > Regards.
> > > > Tejaswini
> > >
> > > the reinstate command is supposed to reinstate the
> device
> > with the
> > > kernel, and it does that. The checker state doesn't
> change
> > until the
> > > next time that the path is checked. I agree that it's
> odd
> > that the
> > > check state switches to faulty as soon as you fail the
> path,
> > but it
> > > doesn't switch back until the next check after you
> reinistate
> > it.
> > >
> > > The issue is that multipathd needs to override the
> checker
> > output,
> > > so that a failed path won't be immeditately
> reinstated. Once
> > the
> > > path comes back, multipathd wants to record the switch
> in the
> > checker
> > > thread, so that it can refresh path information what
> wasn't
> > > automatically done when the path was reinstated.
> However, it
> > may make
> > > more sense to have a different checker state for when
> the
> > device is
> > > in the failed state, so that it's obvious that the
> checker
> > state is
> > > being overruled.
> > >
> > > -Ben
> > >
> > > > --
> > > > dm-devel mailing list
> > > > [3][5][6]dm-devel@redhat.com
> > > >
> [4][6][7]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > --
> > > dm-devel mailing list
> > > [5][7][8]dm-devel@redhat.com
> > >
> [6][8][9]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[9][10]tejaswinipoluri3@gmail.com
> > > 2. mailto:[10][11]bmarzins@redhat.com
> > > 3. mailto:[11][12]dm-devel@redhat.com
> > > 4.
> [12][13]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 5. mailto:[13][14]dm-devel@redhat.com
> > > 6.
> [14][15]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:[16]tejaswinipoluri3@gmail.com
> > 2. mailto:[17]bmarzins@redhat.com
> > 3. mailto:[18]tejaswinipoluri3@gmail.com
> > 4. mailto:[19]bmarzins@redhat.com
> > 5. mailto:[20]dm-devel@redhat.com
> > 6. [21]https://www.redhat.com/mailman/listinfo/dm-devel
> > 7. mailto:[22]dm-devel@redhat.com
> > 8. [23]https://www.redhat.com/mailman/listinfo/dm-devel
> > 9. mailto:[24]tejaswinipoluri3@gmail.com
> > 10. mailto:[25]bmarzins@redhat.com
> > 11. mailto:[26]dm-devel@redhat.com
> > 12. [27]https://www.redhat.com/mailman/listinfo/dm-devel
> > 13. mailto:[28]dm-devel@redhat.com
> > 14. [29]https://www.redhat.com/mailman/listinfo/dm-devel
>
> References
>
> Visible links
> 1. mailto:bmarzins@redhat.com
> 2. mailto:tejaswinipoluri3@gmail.com
> 3. mailto:bmarzins@redhat.com
> 4. mailto:tejaswinipoluri3@gmail.com
> 5. mailto:bmarzins@redhat.com
> 6. mailto:dm-devel@redhat.com
> 7. https://www.redhat.com/mailman/listinfo/dm-devel
> 8. mailto:dm-devel@redhat.com
> 9. https://www.redhat.com/mailman/listinfo/dm-devel
> 10. mailto:tejaswinipoluri3@gmail.com
> 11. mailto:bmarzins@redhat.com
> 12. mailto:dm-devel@redhat.com
> 13. https://www.redhat.com/mailman/listinfo/dm-devel
> 14. mailto:dm-devel@redhat.com
> 15. https://www.redhat.com/mailman/listinfo/dm-devel
> 16. mailto:tejaswinipoluri3@gmail.com
> 17. mailto:bmarzins@redhat.com
> 18. mailto:tejaswinipoluri3@gmail.com
> 19. mailto:bmarzins@redhat.com
> 20. mailto:dm-devel@redhat.com
> 21. https://www.redhat.com/mailman/listinfo/dm-devel
> 22. mailto:dm-devel@redhat.com
> 23. https://www.redhat.com/mailman/listinfo/dm-devel
> 24. mailto:tejaswinipoluri3@gmail.com
> 25. mailto:bmarzins@redhat.com
> 26. mailto:dm-devel@redhat.com
> 27. https://www.redhat.com/mailman/listinfo/dm-devel
> 28. mailto:dm-devel@redhat.com
> 29. https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-06-25 23:02 ` Benjamin Marzinski
@ 2015-06-26 6:51 ` Tejaswini Poluri
2015-06-29 19:20 ` Benjamin Marzinski
0 siblings, 1 reply; 11+ messages in thread
From: Tejaswini Poluri @ 2015-06-26 6:51 UTC (permalink / raw)
To: Benjamin Marzinski; +Cc: device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 21176 bytes --]
Yes I agree that having the same code in both cli_add_map() and ev_add_map
is not necessary. Hence I would suggest removing get_refwwid() code from
ev_add_map as it is not being used by anyone.
ev_add_map(param, NULL, vecs) would create the multipath device by using
the get_refwwid() code and but all the functions above it like
(dm_get_minor, dm_get_major and dm_mapname) would fail and it wouldn't
enter any of the other code in ev_add_map like
1.dm_map_present,
2.add_map_without_path
3. sync_map_state
which are responsible for registering the map and displaying it.
So, I think moving the below code from ev_add_map to cli_add_map should be
a good idea right.
r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
>
> if (refwwid) {
> r = coalesce_paths(vecs, NULL, refwwid,0);
> dm_lib_release();
> }
What do u think?
Regards,
Tejaswini
On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski <bmarzins@redhat.com>
wrote:
> On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:
> > Hi Ben,
> >
> > This is regarding the add map issue I have been discussing. Posting
> the
> > issue again to remind.
> >
> > Case 1 : remove and add map.
> > root@x86-generic-64:~# multipathd -k'show maps'
> > name sysfs uuid
> > dmpath0 dm-0 1IET_00010001
> > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > ok
> > root@x86-generic-64:~# multipathd -k'show maps'
> > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > ok
> > root@x86-generic-64:~# multipathd -k'show maps'
> > root@x86-generic-64:~#
> > Once a map is removed, we are able to add it only using #multipath
> > command and not using multipathd tools.
> >
> > I have fixed the problem with two approaches. I would like you to
> review
> > the same.
> > Patch1 : By making 'remove map dmpath0' to remove only the map and
> not the
> > device. I have added extra functions discard_map and dm_remove_map so
> as
> > to not interfere with the existing code.
> >
> > Patch 2: The approach you have suggested.By getting wwid from the
> mapname
> > and doing coalesce_paths. I have just moved the following code in
> > ev_add_map to cli_add_map.
>
> This is the general idea we'd like to go with. However, looking at the
> latest upstream code, I don't think you should pull code in from
> ev_add_map() to cli_add_map() like your patch does. cli_add_map()
> already calls ev_add_map(), and ev_add_map() is certainly able to add
> the map if it doesn't already exist.
>
> You would just need to call it with
>
> ev_add_map(param, NULL, vecs);
>
> and ev_add_map() will happily create you a new multipath device. All
> you need to do is make sure that all the functions that ev_add_map()
> calls with alias can accept a NULL value there.
>
> This might not be the best way to go about this, however. It turns out
> that right now, even though ev_add_map() technically has the ability to
> create new maps, nothing currently uses it, and it really doesn't make
> sense for it to be there. Instead of just copying that code, you could
> pull the map creation code out of ev_add_map() and add it to
> cli_add_map(), for those situations where the requested device doesn't
> already exist.
>
> But having the code in both cli_add_map() and ev_add_map() when one
> already calls the other doesn't seem necessary.
>
> -Ben
>
>
> >
> > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> >
> > if (refwwid) {
> > r = coalesce_paths(vecs, NULL, refwwid,0);
> > dm_lib_release();
> > }
> >
> > changed dev to param.
> >
> > I have tested the same in all 3 versions -0.4.8, 0.4.9 and 0.5.0. It
> would
> > be great if you can review the same so that it doesn't cause any extra
> > side effects.
> > I guess Patch2 is the way u have suggested me in the previous mail.
> Please
> > review it and share your views.
> > Regards,
> > Tejaswini
> > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > <[1]bmarzins@redhat.com> wrote:
> >
> > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri wrote:
> > >
> > > > We are testing multipathd tools with all the possible
> options
> > and the
> > > > following fails.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only using
> > #multipath
> > > > command and not using multipathd tools.
> > >
> > > It is working the way it was designed, but possibly it would
> make
> > sense
> > > to change the design.
> > >
> > > You have mentioned that it would make sense to change the
> design to
> > add
> > > map. Are there plans to change the design ?
> > > I am trying to understand the code flow to change the design.
> Can
> > you
> > > guide me if we should stop removing the device from in the
> remove
> > map code
> > > flow or start adding the device and the map in the add map code
> > flow.
> > >
> > > have tried to understand the remove map code flow of
> multipathd in
> > 0.4.8
> > > code.
> >
> > I think that we want multipath to actually remove the map (instead
> of
> > just not monitoring it) when you call "remove map <map>". We just
> want
> > "add map <map>" to try to create the map if it doesn't exist. To do
> > that, you would need to first firgure out what WWID is associated
> with
> > <map>. Presumably, <map> could either be an alias, wwid, or even the
> > name of a path in the map. Once you found the map, you would have to
> > call the code to create the map.
> >
> > Also, to answer your IRC question, no the 0.4.8 code is not still
> being
> > developed upstream. All upstream patches only go against the
> current
> > head. There are no other upstream branches.
> >
> > -Ben
> > >
> > > ev_remove_map (char * devname, struct vectors * vecs)
> > >
> > > flush_map(mpp, vecs);
> > >
> > > dm_flush_map(mpp->alias,
> DEFAULT_TARGET);
> > >
> > > if (!dm_map_present(mapname))
> > >
> > > return 0;
> > >
> > > if (dm_type(mapname, type) <= 0)
> > >
> > > return 1;
> > >
> > > if (dm_remove_partmaps(mapname))
> > >
> > > return 1;
> > >
> > > if (dm_get_opencount(mapname)) {
> > >
> > > condlog(2, "%s: map in use", mapname);
> > >
> > > return 1;
> > >
> > > }
> > >
> > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > >
> > > if (r) {
> > >
> > > condlog(4, "multipath map %s removed", mapname);
> > >
> > > return 0;
> > >
> > > }
> > >
> > >
> > >
> > > orphan_paths(vecs->pathvec, mpp);
> > >
> > > remove_map(mpp, vecs,
> stop_waiter_thread,
> > 1);
> > >
> > > Is removing this below line, the right step to stop removing
> the
> > device ?
> > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > >
> > > Regards,
> > >
> > > Tejaswini
> > >
> > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > > <[1][2]tejaswinipoluri3@gmail.com> wrote:
> > >
> > > Thanks a lot Ben for the quick and detailed reply. I have
> been
> > > struggling to understand and conclude the issues with
> multipath
> > as I am
> > > the only one working from my team. Your inputs help me a lot.
> > Thanks
> > > again.
> > > Regards,
> > > Tejaswini
> > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > > <[2][3]bmarzins@redhat.com> wrote:
> > >
> > > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini Poluri
> > wrote:
> > > > Hii Ben,
> > > >
> > > > We are testing multipathd tools with all the possible
> > options and
> > > the
> > > > following fails.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only
> using
> > > #multipath
> > > > command and not using multipathd tools.
> > >
> > > It is working the way it was designed, but possibly it
> would
> > make
> > > sense
> > > to change the design. The "remove map" command, not only
> stops
> > > multipathd from monitoring the multipath device, but it
> removes
> > it
> > > from
> > > the system as well. The "add map" command makes multipath
> > monitor an
> > > already existing multipath device that in wasn't previously
> > > monitoring.
> > > These commands do this for historical reasons. multipathd
> > wasn't
> > > originally in charge of creating multipath devices,
> multipath
> > was.
> > > Once
> > > it had created the device, it ran
> > >
> > > multipathd -k"add map <MAP>"
> > >
> > > to make multipathd start monitoring it. However things
> haven't
> > worked
> > > this way since RHEL4, so possibly "add map" should actually
> > create the
> > > device if it doesn't currently exist.
> > > > Case 2 : Active paths test case
> > > > # while true ; do sleep 3 ; multipathd -k'remove path
> sdb'
> > ;
> > > multipathd
> > > > -k'add path sdb' ; multipathd -k'show maps status' ;
> done
> > > > ok
> > > > ok
> > > > name failback queueing paths dm-st
> > > > dmpath0 - - 1 active // It should be 2.
> > >
> > > This is simply a timing issue. What you are seeing it the
> > number of
> > > active paths. These are paths that the kernel can use. The
> > "add path"
> > > command doesn't update the kernel state. This happens
> later in
> > > response
> > > to the kernel reloading the device table. So, in a second
> or
> > two, this
> > > will say 2, as expected.
> > >
> > > > We would like to know if the test cases are valid and
> if
> > these
> > > are bugs or
> > > > any design issues.
> > > >
> > > > Case 3 : Fail path and reinstate path
> > > > root@x86-generic-64:~# multipathd -k"fail path sdc";
> > multipathd
> > > > -k'reinstate path sdc'; multipathd -k"show paths";
> > > > > [ 3962.708523] device-mapper: multipath: Failing
> path
> > 8:32.
> > > > > ok
> > > > > ok
> > > > > hcil dev dev_t pri dm_st chk_st next_check
> > > > > 4:0:0:1 sdc 8:32 1 [active][faulty] ..........
> > 1/20
> > > <==CHECK
> > > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........
> > 4/20
> > > > sdc path becomes [active][ready] only after the
> polling
> > interval
> > > but not
> > > > immediately after the reinstate path command.
> > > > You have answered that this is a design issue. But we
> have
> > heard
> > > from our
> > > > test team that the same test case works in RHEL6. Did
> you
> > observe
> > > it?
> > > > I am also finding that the test cases fail because we
> are
> > trying
> > > to do
> > > > multiple commands at one shot. Please share your
> thoughts
> > so
> > > that it
> > > > could help me in debugging the issues further.
> > > >
> > >
> > > It's totally possible that the checker state is immediately
> > updated in
> > > RHEL6. Like I said before, what it currently does,
> although
> > correct,
> > > is confusing, and perhaps we need a different checker
> state for
> > paths
> > > where the "fail path" command has been used.
> > >
> > > -Ben
> > > > Regards,
> > > > Tejaswini
> > > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini Poluri
> > > > <[1][3][4]tejaswinipoluri3@gmail.com> wrote:
> > > >
> > > > Thanks a lot Ben. I will look into it more.
> > > > On Mon, May 18, 2015 at 9:57 PM, Benjamin Marzinski
> > > > <[2][4][5]bmarzins@redhat.com> wrote:
> > > >
> > > > On Mon, May 18, 2015 at 02:09:27PM +0530,
> Tejaswini
> > Poluri
> > > wrote:
> > > > > Hii,
> > > > > We are trying to test multipath setup in our
> > target and
> > > tried the
> > > > various
> > > > > commands of multipathd demaon and we find the
> > following
> > > error:
> > > > > root@x86-generic-64:~# multipathd -k"fail
> path
> > sdc";
> > > multipathd
> > > > > -k'reinstate path
> > > > > sdc'; multipathd -k"show paths";
> > > > > [ 3962.708523] device-mapper: multipath:
> Failing
> > > path 8:32.
> > > > > ok
> > > > > ok
> > > > > hcil dev dev_t pri dm_st chk_st
> next_check
> > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> ..........
> > 1/20
> > > <<<===
> > > > CHECK
> > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> XX........
> > 4/20
> > > > > sdc path becomes [active][ready] only after
> the
> > polling
> > > interval
> > > > but not
> > > > > immediately after the reinstate path
> command.
> > > > > I am observing this in latest multipath
> tools in
> > ubuntu
> > > machine
> > > > as well.
> > > > > Please let me know if its a known issue or
> if I
> > am doing
> > > > something wrong.
> > > > > Regards.
> > > > > Tejaswini
> > > >
> > > > the reinstate command is supposed to reinstate the
> > device
> > > with the
> > > > kernel, and it does that. The checker state
> doesn't
> > change
> > > until the
> > > > next time that the path is checked. I agree that
> it's
> > odd
> > > that the
> > > > check state switches to faulty as soon as you
> fail the
> > path,
> > > but it
> > > > doesn't switch back until the next check after you
> > reinistate
> > > it.
> > > >
> > > > The issue is that multipathd needs to override the
> > checker
> > > output,
> > > > so that a failed path won't be immeditately
> > reinstated. Once
> > > the
> > > > path comes back, multipathd wants to record the
> switch
> > in the
> > > checker
> > > > thread, so that it can refresh path information
> what
> > wasn't
> > > > automatically done when the path was reinstated.
> > However, it
> > > may make
> > > > more sense to have a different checker state for
> when
> > the
> > > device is
> > > > in the failed state, so that it's obvious that the
> > checker
> > > state is
> > > > being overruled.
> > > >
> > > > -Ben
> > > >
> > > > > --
> > > > > dm-devel mailing list
> > > > > [3][5][6]dm-devel@redhat.com
> > > > >
> > [4][6][7]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > --
> > > > dm-devel mailing list
> > > > [5][7][8]dm-devel@redhat.com
> > > >
> > [6][8][9]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[9][10]tejaswinipoluri3@gmail.com
> > > > 2. mailto:[10][11]bmarzins@redhat.com
> > > > 3. mailto:[11][12]dm-devel@redhat.com
> > > > 4.
> > [12][13]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 5. mailto:[13][14]dm-devel@redhat.com
> > > > 6.
> > [14][15]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[16]tejaswinipoluri3@gmail.com
> > > 2. mailto:[17]bmarzins@redhat.com
> > > 3. mailto:[18]tejaswinipoluri3@gmail.com
> > > 4. mailto:[19]bmarzins@redhat.com
> > > 5. mailto:[20]dm-devel@redhat.com
> > > 6. [21]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 7. mailto:[22]dm-devel@redhat.com
> > > 8. [23]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 9. mailto:[24]tejaswinipoluri3@gmail.com
> > > 10. mailto:[25]bmarzins@redhat.com
> > > 11. mailto:[26]dm-devel@redhat.com
> > > 12. [27]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 13. mailto:[28]dm-devel@redhat.com
> > > 14. [29]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:bmarzins@redhat.com
> > 2. mailto:tejaswinipoluri3@gmail.com
> > 3. mailto:bmarzins@redhat.com
> > 4. mailto:tejaswinipoluri3@gmail.com
> > 5. mailto:bmarzins@redhat.com
> > 6. mailto:dm-devel@redhat.com
> > 7. https://www.redhat.com/mailman/listinfo/dm-devel
> > 8. mailto:dm-devel@redhat.com
> > 9. https://www.redhat.com/mailman/listinfo/dm-devel
> > 10. mailto:tejaswinipoluri3@gmail.com
> > 11. mailto:bmarzins@redhat.com
> > 12. mailto:dm-devel@redhat.com
> > 13. https://www.redhat.com/mailman/listinfo/dm-devel
> > 14. mailto:dm-devel@redhat.com
> > 15. https://www.redhat.com/mailman/listinfo/dm-devel
> > 16. mailto:tejaswinipoluri3@gmail.com
> > 17. mailto:bmarzins@redhat.com
> > 18. mailto:tejaswinipoluri3@gmail.com
> > 19. mailto:bmarzins@redhat.com
> > 20. mailto:dm-devel@redhat.com
> > 21. https://www.redhat.com/mailman/listinfo/dm-devel
> > 22. mailto:dm-devel@redhat.com
> > 23. https://www.redhat.com/mailman/listinfo/dm-devel
> > 24. mailto:tejaswinipoluri3@gmail.com
> > 25. mailto:bmarzins@redhat.com
> > 26. mailto:dm-devel@redhat.com
> > 27. https://www.redhat.com/mailman/listinfo/dm-devel
> > 28. mailto:dm-devel@redhat.com
> > 29. https://www.redhat.com/mailman/listinfo/dm-devel
>
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 32736 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-06-26 6:51 ` Tejaswini Poluri
@ 2015-06-29 19:20 ` Benjamin Marzinski
2015-06-30 5:52 ` Tejaswini Poluri
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Marzinski @ 2015-06-29 19:20 UTC (permalink / raw)
To: Tejaswini Poluri; +Cc: device-mapper development
On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri wrote:
> Yes I agree that having the same code in both cli_add_map() and ev_add_map
> is not necessary. Hence I would suggest removing get_refwwid() code from
> ev_add_map as it is not being used by anyone.
>
> ev_add_map(param, NULL, vecs) would create the multipath device by using
> the get_refwwid() code and but all the functions above it like
> (dm_get_minor, dm_get_major and dm_mapname) would fail and it wouldn't
> enter any of the other code in ev_add_map like
> 1.dm_map_present,
> 2.add_map_without_path
> 3. sync_map_state
> which are responsible for registering the map and displaying it.
>
> So, I think moving the below code from ev_add_map to cli_add_map should be
> a good idea right.
>
> r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> >
> > if (refwwid) {
> > r = coalesce_paths(vecs, NULL, refwwid,0);
> > dm_lib_release();
> > }
> What do u think?
I agree. We aren't using the code in ev_add_map, so it's presence there
is simply confusing.
-Ben
>
> Regards,
> Tejaswini
> On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> <[1]bmarzins@redhat.com> wrote:
>
> On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:
> > Hi Ben,
> >
> > This is regarding the add map issue I have been discussing. Posting
> the
> > issue again to remind.
> >
> > Case 1 : remove and add map.
> > root@x86-generic-64:~# multipathd -k'show maps'
> > name sysfs uuid
> > dmpath0 dm-0 1IET_00010001
> > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > ok
> > root@x86-generic-64:~# multipathd -k'show maps'
> > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > ok
> > root@x86-generic-64:~# multipathd -k'show maps'
> > root@x86-generic-64:~#
> > Once a map is removed, we are able to add it only using #multipath
> > command and not using multipathd tools.
> >
> > I have fixed the problem with two approaches. I would like you to
> review
> > the same.
> > Patch1 : By making 'remove map dmpath0' to remove only the map and
> not the
> > device. I have added extra functions discard_map and dm_remove_map
> so as
> > to not interfere with the existing code.
> >
> > Patch 2: The approach you have suggested.By getting wwid from the
> mapname
> > and doing coalesce_paths. I have just moved the following code in
> > ev_add_map to cli_add_map.
>
> This is the general idea we'd like to go with. However, looking at the
> latest upstream code, I don't think you should pull code in from
> ev_add_map() to cli_add_map() like your patch does. cli_add_map()
> already calls ev_add_map(), and ev_add_map() is certainly able to add
> the map if it doesn't already exist.
>
> You would just need to call it with
>
> ev_add_map(param, NULL, vecs);
>
> and ev_add_map() will happily create you a new multipath device. All
> you need to do is make sure that all the functions that ev_add_map()
> calls with alias can accept a NULL value there.
>
> This might not be the best way to go about this, however. It turns out
> that right now, even though ev_add_map() technically has the ability to
> create new maps, nothing currently uses it, and it really doesn't make
> sense for it to be there. Instead of just copying that code, you could
> pull the map creation code out of ev_add_map() and add it to
> cli_add_map(), for those situations where the requested device doesn't
> already exist.
>
> But having the code in both cli_add_map() and ev_add_map() when one
> already calls the other doesn't seem necessary.
>
> -Ben
>
> >
> > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> >
> > if (refwwid) {
> > r = coalesce_paths(vecs, NULL, refwwid,0);
> > dm_lib_release();
> > }
> >
> > changed dev to param.
> >
> > I have tested the same in all 3 versions -0.4.8, 0.4.9 and 0.5.0.
> It would
> > be great if you can review the same so that it doesn't cause any
> extra
> > side effects.
> > I guess Patch2 is the way u have suggested me in the previous mail.
> Please
> > review it and share your views.
> > Regards,
> > Tejaswini
> > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > <[1][2]bmarzins@redhat.com> wrote:
> >
> > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri wrote:
> > >
> > > > We are testing multipathd tools with all the possible
> options
> > and the
> > > > following fails.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only using
> > #multipath
> > > > command and not using multipathd tools.
> > >
> > > It is working the way it was designed, but possibly it would
> make
> > sense
> > > to change the design.
> > >
> > > You have mentioned that it would make sense to change the
> design to
> > add
> > > map. Are there plans to change the design ?
> > > I am trying to understand the code flow to change the
> design. Can
> > you
> > > guide me if we should stop removing the device from in the
> remove
> > map code
> > > flow or start adding the device and the map in the add map
> code
> > flow.
> > >
> > > have tried to understand the remove map code flow of
> multipathd in
> > 0.4.8
> > > code.
> >
> > I think that we want multipath to actually remove the map
> (instead of
> > just not monitoring it) when you call "remove map <map>". We just
> want
> > "add map <map>" to try to create the map if it doesn't exist. To
> do
> > that, you would need to first firgure out what WWID is associated
> with
> > <map>. Presumably, <map> could either be an alias, wwid, or even
> the
> > name of a path in the map. Once you found the map, you would have
> to
> > call the code to create the map.
> >
> > Also, to answer your IRC question, no the 0.4.8 code is not still
> being
> > developed upstream. All upstream patches only go against the
> current
> > head. There are no other upstream branches.
> >
> > -Ben
> > >
> > > ev_remove_map (char * devname, struct vectors * vecs)
> > >
> > > flush_map(mpp, vecs);
> > >
> > > dm_flush_map(mpp->alias,
> DEFAULT_TARGET);
> > >
> > > if
> (!dm_map_present(mapname))
> > >
> > > return 0;
> > >
> > > if (dm_type(mapname, type) <= 0)
> > >
> > > return 1;
> > >
> > > if (dm_remove_partmaps(mapname))
> > >
> > > return 1;
> > >
> > > if (dm_get_opencount(mapname)) {
> > >
> > > condlog(2, "%s: map in use", mapname);
> > >
> > > return 1;
> > >
> > > }
> > >
> > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > >
> > > if (r) {
> > >
> > > condlog(4, "multipath map %s removed",
> mapname);
> > >
> > > return 0;
> > >
> > > }
> > >
> > >
> > >
> > > orphan_paths(vecs->pathvec, mpp);
> > >
> > > remove_map(mpp, vecs,
> stop_waiter_thread,
> > 1);
> > >
> > > Is removing this below line, the right step to stop removing
> the
> > device ?
> > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > >
> > > Regards,
> > >
> > > Tejaswini
> > >
> > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > > <[1][2][3]tejaswinipoluri3@gmail.com> wrote:
> > >
> > > Thanks a lot Ben for the quick and detailed reply. I have
> been
> > > struggling to understand and conclude the issues with
> multipath
> > as I am
> > > the only one working from my team. Your inputs help me a
> lot.
> > Thanks
> > > again.
> > > Regards,
> > > Tejaswini
> > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > > <[2][3][4]bmarzins@redhat.com> wrote:
> > >
> > > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini
> Poluri
> > wrote:
> > > > Hii Ben,
> > > >
> > > > We are testing multipathd tools with all the
> possible
> > options and
> > > the
> > > > following fails.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only
> using
> > > #multipath
> > > > command and not using multipathd tools.
> > >
> > > It is working the way it was designed, but possibly it
> would
> > make
> > > sense
> > > to change the design. The "remove map" command, not
> only stops
> > > multipathd from monitoring the multipath device, but it
> removes
> > it
> > > from
> > > the system as well. The "add map" command makes
> multipath
> > monitor an
> > > already existing multipath device that in wasn't
> previously
> > > monitoring.
> > > These commands do this for historical reasons.
> multipathd
> > wasn't
> > > originally in charge of creating multipath devices,
> multipath
> > was.
> > > Once
> > > it had created the device, it ran
> > >
> > > multipathd -k"add map <MAP>"
> > >
> > > to make multipathd start monitoring it. However things
> haven't
> > worked
> > > this way since RHEL4, so possibly "add map" should
> actually
> > create the
> > > device if it doesn't currently exist.
> > > > Case 2 : Active paths test case
> > > > # while true ; do sleep 3 ; multipathd -k'remove
> path sdb'
> > ;
> > > multipathd
> > > > -k'add path sdb' ; multipathd -k'show maps status'
> ; done
> > > > ok
> > > > ok
> > > > name failback queueing paths dm-st
> > > > dmpath0 - - 1 active // It should be 2.
> > >
> > > This is simply a timing issue. What you are seeing it
> the
> > number of
> > > active paths. These are paths that the kernel can use.
> The
> > "add path"
> > > command doesn't update the kernel state. This happens
> later in
> > > response
> > > to the kernel reloading the device table. So, in a
> second or
> > two, this
> > > will say 2, as expected.
> > >
> > > > We would like to know if the test cases are valid
> and if
> > these
> > > are bugs or
> > > > any design issues.
> > > >
> > > > Case 3 : Fail path and reinstate path
> > > > root@x86-generic-64:~# multipathd -k"fail path
> sdc";
> > multipathd
> > > > -k'reinstate path sdc'; multipathd -k"show paths";
> > > > > [ 3962.708523] device-mapper: multipath:
> Failing path
> > 8:32.
> > > > > ok
> > > > > ok
> > > > > hcil dev dev_t pri dm_st chk_st
> next_check
> > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> ..........
> > 1/20
> > > <==CHECK
> > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> XX........
> > 4/20
> > > > sdc path becomes [active][ready] only after the
> polling
> > interval
> > > but not
> > > > immediately after the reinstate path command.
> > > > You have answered that this is a design issue. But
> we have
> > heard
> > > from our
> > > > test team that the same test case works in RHEL6.
> Did you
> > observe
> > > it?
> > > > I am also finding that the test cases fail because
> we are
> > trying
> > > to do
> > > > multiple commands at one shot. Please share your
> thoughts
> > so
> > > that it
> > > > could help me in debugging the issues further.
> > > >
> > >
> > > It's totally possible that the checker state is
> immediately
> > updated in
> > > RHEL6. Like I said before, what it currently does,
> although
> > correct,
> > > is confusing, and perhaps we need a different checker
> state for
> > paths
> > > where the "fail path" command has been used.
> > >
> > > -Ben
> > > > Regards,
> > > > Tejaswini
> > > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini Poluri
> > > > <[1][3][4][5]tejaswinipoluri3@gmail.com> wrote:
> > > >
> > > > Thanks a lot Ben. I will look into it more.
> > > > On Mon, May 18, 2015 at 9:57 PM, Benjamin
> Marzinski
> > > > <[2][4][5][6]bmarzins@redhat.com> wrote:
> > > >
> > > > On Mon, May 18, 2015 at 02:09:27PM +0530,
> Tejaswini
> > Poluri
> > > wrote:
> > > > > Hii,
> > > > > We are trying to test multipath setup in
> our
> > target and
> > > tried the
> > > > various
> > > > > commands of multipathd demaon and we find
> the
> > following
> > > error:
> > > > > root@x86-generic-64:~# multipathd -k"fail
> path
> > sdc";
> > > multipathd
> > > > > -k'reinstate path
> > > > > sdc'; multipathd -k"show paths";
> > > > > [ 3962.708523] device-mapper: multipath:
> Failing
> > > path 8:32.
> > > > > ok
> > > > > ok
> > > > > hcil dev dev_t pri dm_st chk_st
> next_check
> > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> ..........
> > 1/20
> > > <<<===
> > > > CHECK
> > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> XX........
> > 4/20
> > > > > sdc path becomes [active][ready] only
> after the
> > polling
> > > interval
> > > > but not
> > > > > immediately after the reinstate path
> command.
> > > > > I am observing this in latest multipath
> tools in
> > ubuntu
> > > machine
> > > > as well.
> > > > > Please let me know if its a known issue or
> if I
> > am doing
> > > > something wrong.
> > > > > Regards.
> > > > > Tejaswini
> > > >
> > > > the reinstate command is supposed to reinstate
> the
> > device
> > > with the
> > > > kernel, and it does that. The checker state
> doesn't
> > change
> > > until the
> > > > next time that the path is checked. I agree
> that it's
> > odd
> > > that the
> > > > check state switches to faulty as soon as you
> fail the
> > path,
> > > but it
> > > > doesn't switch back until the next check after
> you
> > reinistate
> > > it.
> > > >
> > > > The issue is that multipathd needs to override
> the
> > checker
> > > output,
> > > > so that a failed path won't be immeditately
> > reinstated. Once
> > > the
> > > > path comes back, multipathd wants to record the
> switch
> > in the
> > > checker
> > > > thread, so that it can refresh path information
> what
> > wasn't
> > > > automatically done when the path was
> reinstated.
> > However, it
> > > may make
> > > > more sense to have a different checker state
> for when
> > the
> > > device is
> > > > in the failed state, so that it's obvious that
> the
> > checker
> > > state is
> > > > being overruled.
> > > >
> > > > -Ben
> > > >
> > > > > --
> > > > > dm-devel mailing list
> > > > > [3][5][6][7]dm-devel@redhat.com
> > > > >
> > [4][6][7][8]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > --
> > > > dm-devel mailing list
> > > > [5][7][8][9]dm-devel@redhat.com
> > > >
> > [6][8][9][10]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[9][10][11]tejaswinipoluri3@gmail.com
> > > > 2. mailto:[10][11][12]bmarzins@redhat.com
> > > > 3. mailto:[11][12][13]dm-devel@redhat.com
> > > > 4.
> > [12][13][14]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 5. mailto:[13][14][15]dm-devel@redhat.com
> > > > 6.
> > [14][15][16]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[16][17]tejaswinipoluri3@gmail.com
> > > 2. mailto:[17][18]bmarzins@redhat.com
> > > 3. mailto:[18][19]tejaswinipoluri3@gmail.com
> > > 4. mailto:[19][20]bmarzins@redhat.com
> > > 5. mailto:[20][21]dm-devel@redhat.com
> > > 6. [21][22]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 7. mailto:[22][23]dm-devel@redhat.com
> > > 8. [23][24]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 9. mailto:[24][25]tejaswinipoluri3@gmail.com
> > > 10. mailto:[25][26]bmarzins@redhat.com
> > > 11. mailto:[26][27]dm-devel@redhat.com
> > > 12. [27][28]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 13. mailto:[28][29]dm-devel@redhat.com
> > > 14. [29][30]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:[31]bmarzins@redhat.com
> > 2. mailto:[32]tejaswinipoluri3@gmail.com
> > 3. mailto:[33]bmarzins@redhat.com
> > 4. mailto:[34]tejaswinipoluri3@gmail.com
> > 5. mailto:[35]bmarzins@redhat.com
> > 6. mailto:[36]dm-devel@redhat.com
> > 7. [37]https://www.redhat.com/mailman/listinfo/dm-devel
> > 8. mailto:[38]dm-devel@redhat.com
> > 9. [39]https://www.redhat.com/mailman/listinfo/dm-devel
> > 10. mailto:[40]tejaswinipoluri3@gmail.com
> > 11. mailto:[41]bmarzins@redhat.com
> > 12. mailto:[42]dm-devel@redhat.com
> > 13. [43]https://www.redhat.com/mailman/listinfo/dm-devel
> > 14. mailto:[44]dm-devel@redhat.com
> > 15. [45]https://www.redhat.com/mailman/listinfo/dm-devel
> > 16. mailto:[46]tejaswinipoluri3@gmail.com
> > 17. mailto:[47]bmarzins@redhat.com
> > 18. mailto:[48]tejaswinipoluri3@gmail.com
> > 19. mailto:[49]bmarzins@redhat.com
> > 20. mailto:[50]dm-devel@redhat.com
> > 21. [51]https://www.redhat.com/mailman/listinfo/dm-devel
> > 22. mailto:[52]dm-devel@redhat.com
> > 23. [53]https://www.redhat.com/mailman/listinfo/dm-devel
> > 24. mailto:[54]tejaswinipoluri3@gmail.com
> > 25. mailto:[55]bmarzins@redhat.com
> > 26. mailto:[56]dm-devel@redhat.com
> > 27. [57]https://www.redhat.com/mailman/listinfo/dm-devel
> > 28. mailto:[58]dm-devel@redhat.com
> > 29. [59]https://www.redhat.com/mailman/listinfo/dm-devel
>
> References
>
> Visible links
> 1. mailto:bmarzins@redhat.com
> 2. mailto:bmarzins@redhat.com
> 3. mailto:tejaswinipoluri3@gmail.com
> 4. mailto:bmarzins@redhat.com
> 5. mailto:tejaswinipoluri3@gmail.com
> 6. mailto:bmarzins@redhat.com
> 7. mailto:dm-devel@redhat.com
> 8. https://www.redhat.com/mailman/listinfo/dm-devel
> 9. mailto:dm-devel@redhat.com
> 10. https://www.redhat.com/mailman/listinfo/dm-devel
> 11. mailto:tejaswinipoluri3@gmail.com
> 12. mailto:bmarzins@redhat.com
> 13. mailto:dm-devel@redhat.com
> 14. https://www.redhat.com/mailman/listinfo/dm-devel
> 15. mailto:dm-devel@redhat.com
> 16. https://www.redhat.com/mailman/listinfo/dm-devel
> 17. mailto:tejaswinipoluri3@gmail.com
> 18. mailto:bmarzins@redhat.com
> 19. mailto:tejaswinipoluri3@gmail.com
> 20. mailto:bmarzins@redhat.com
> 21. mailto:dm-devel@redhat.com
> 22. https://www.redhat.com/mailman/listinfo/dm-devel
> 23. mailto:dm-devel@redhat.com
> 24. https://www.redhat.com/mailman/listinfo/dm-devel
> 25. mailto:tejaswinipoluri3@gmail.com
> 26. mailto:bmarzins@redhat.com
> 27. mailto:dm-devel@redhat.com
> 28. https://www.redhat.com/mailman/listinfo/dm-devel
> 29. mailto:dm-devel@redhat.com
> 30. https://www.redhat.com/mailman/listinfo/dm-devel
> 31. mailto:bmarzins@redhat.com
> 32. mailto:tejaswinipoluri3@gmail.com
> 33. mailto:bmarzins@redhat.com
> 34. mailto:tejaswinipoluri3@gmail.com
> 35. mailto:bmarzins@redhat.com
> 36. mailto:dm-devel@redhat.com
> 37. https://www.redhat.com/mailman/listinfo/dm-devel
> 38. mailto:dm-devel@redhat.com
> 39. https://www.redhat.com/mailman/listinfo/dm-devel
> 40. mailto:tejaswinipoluri3@gmail.com
> 41. mailto:bmarzins@redhat.com
> 42. mailto:dm-devel@redhat.com
> 43. https://www.redhat.com/mailman/listinfo/dm-devel
> 44. mailto:dm-devel@redhat.com
> 45. https://www.redhat.com/mailman/listinfo/dm-devel
> 46. mailto:tejaswinipoluri3@gmail.com
> 47. mailto:bmarzins@redhat.com
> 48. mailto:tejaswinipoluri3@gmail.com
> 49. mailto:bmarzins@redhat.com
> 50. mailto:dm-devel@redhat.com
> 51. https://www.redhat.com/mailman/listinfo/dm-devel
> 52. mailto:dm-devel@redhat.com
> 53. https://www.redhat.com/mailman/listinfo/dm-devel
> 54. mailto:tejaswinipoluri3@gmail.com
> 55. mailto:bmarzins@redhat.com
> 56. mailto:dm-devel@redhat.com
> 57. https://www.redhat.com/mailman/listinfo/dm-devel
> 58. mailto:dm-devel@redhat.com
> 59. https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-06-29 19:20 ` Benjamin Marzinski
@ 2015-06-30 5:52 ` Tejaswini Poluri
2015-07-06 17:45 ` Benjamin Marzinski
0 siblings, 1 reply; 11+ messages in thread
From: Tejaswini Poluri @ 2015-06-30 5:52 UTC (permalink / raw)
To: Benjamin Marzinski; +Cc: device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 28746 bytes --]
Thanks Ben. So should I push the code to the upstream and get an approval?
Regards,
Tejaswini
On Tue, Jun 30, 2015 at 12:50 AM, Benjamin Marzinski <bmarzins@redhat.com>
wrote:
> On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri wrote:
> > Yes I agree that having the same code in both cli_add_map() and
> ev_add_map
> > is not necessary. Hence I would suggest removing get_refwwid() code
> from
> > ev_add_map as it is not being used by anyone.
> >
> > ev_add_map(param, NULL, vecs) would create the multipath device by
> using
> > the get_refwwid() code and but all the functions above it like
> > (dm_get_minor, dm_get_major and dm_mapname) would fail and it wouldn't
> > enter any of the other code in ev_add_map like
> > 1.dm_map_present,
> > 2.add_map_without_path
> > 3. sync_map_state
> > which are responsible for registering the map and displaying it.
> >
> > So, I think moving the below code from ev_add_map to cli_add_map
> should be
> > a good idea right.
> >
> > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > >
> > > if (refwwid) {
> > > r = coalesce_paths(vecs, NULL, refwwid,0);
> > > dm_lib_release();
> > > }
> > What do u think?
>
> I agree. We aren't using the code in ev_add_map, so it's presence there
> is simply confusing.
>
> -Ben
>
> >
> > Regards,
> > Tejaswini
> > On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> > <[1]bmarzins@redhat.com> wrote:
> >
> > On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:
> > > Hi Ben,
> > >
> > > This is regarding the add map issue I have been discussing.
> Posting
> > the
> > > issue again to remind.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> #multipath
> > > command and not using multipathd tools.
> > >
> > > I have fixed the problem with two approaches. I would like you
> to
> > review
> > > the same.
> > > Patch1 : By making 'remove map dmpath0' to remove only the map
> and
> > not the
> > > device. I have added extra functions discard_map and
> dm_remove_map
> > so as
> > > to not interfere with the existing code.
> > >
> > > Patch 2: The approach you have suggested.By getting wwid from
> the
> > mapname
> > > and doing coalesce_paths. I have just moved the following code
> in
> > > ev_add_map to cli_add_map.
> >
> > This is the general idea we'd like to go with. However, looking at
> the
> > latest upstream code, I don't think you should pull code in from
> > ev_add_map() to cli_add_map() like your patch does. cli_add_map()
> > already calls ev_add_map(), and ev_add_map() is certainly able to
> add
> > the map if it doesn't already exist.
> >
> > You would just need to call it with
> >
> > ev_add_map(param, NULL, vecs);
> >
> > and ev_add_map() will happily create you a new multipath device.
> All
> > you need to do is make sure that all the functions that ev_add_map()
> > calls with alias can accept a NULL value there.
> >
> > This might not be the best way to go about this, however. It turns
> out
> > that right now, even though ev_add_map() technically has the
> ability to
> > create new maps, nothing currently uses it, and it really doesn't
> make
> > sense for it to be there. Instead of just copying that code, you
> could
> > pull the map creation code out of ev_add_map() and add it to
> > cli_add_map(), for those situations where the requested device
> doesn't
> > already exist.
> >
> > But having the code in both cli_add_map() and ev_add_map() when one
> > already calls the other doesn't seem necessary.
> >
> > -Ben
> >
> > >
> > > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > >
> > > if (refwwid) {
> > > r = coalesce_paths(vecs, NULL, refwwid,0);
> > > dm_lib_release();
> > > }
> > >
> > > changed dev to param.
> > >
> > > I have tested the same in all 3 versions -0.4.8, 0.4.9 and
> 0.5.0.
> > It would
> > > be great if you can review the same so that it doesn't cause
> any
> > extra
> > > side effects.
> > > I guess Patch2 is the way u have suggested me in the previous
> mail.
> > Please
> > > review it and share your views.
> > > Regards,
> > > Tejaswini
> > > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > > <[1][2]bmarzins@redhat.com> wrote:
> > >
> > > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri
> wrote:
> > > >
> > > > > We are testing multipathd tools with all the
> possible
> > options
> > > and the
> > > > > following fails.
> > > > >
> > > > > Case 1 : remove and add map.
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > name sysfs uuid
> > > > > dmpath0 dm-0 1IET_00010001
> > > > > root@x86-generic-64:~# multipathd -k'remove map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~# multipathd -k'add map
> dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~#
> > > > > Once a map is removed, we are able to add it only
> using
> > > #multipath
> > > > > command and not using multipathd tools.
> > > >
> > > > It is working the way it was designed, but possibly it
> would
> > make
> > > sense
> > > > to change the design.
> > > >
> > > > You have mentioned that it would make sense to change
> the
> > design to
> > > add
> > > > map. Are there plans to change the design ?
> > > > I am trying to understand the code flow to change the
> > design. Can
> > > you
> > > > guide me if we should stop removing the device from in
> the
> > remove
> > > map code
> > > > flow or start adding the device and the map in the add
> map
> > code
> > > flow.
> > > >
> > > > have tried to understand the remove map code flow of
> > multipathd in
> > > 0.4.8
> > > > code.
> > >
> > > I think that we want multipath to actually remove the map
> > (instead of
> > > just not monitoring it) when you call "remove map <map>". We
> just
> > want
> > > "add map <map>" to try to create the map if it doesn't
> exist. To
> > do
> > > that, you would need to first firgure out what WWID is
> associated
> > with
> > > <map>. Presumably, <map> could either be an alias, wwid, or
> even
> > the
> > > name of a path in the map. Once you found the map, you would
> have
> > to
> > > call the code to create the map.
> > >
> > > Also, to answer your IRC question, no the 0.4.8 code is not
> still
> > being
> > > developed upstream. All upstream patches only go against the
> > current
> > > head. There are no other upstream branches.
> > >
> > > -Ben
> > > >
> > > > ev_remove_map (char * devname, struct vectors * vecs)
> > > >
> > > > flush_map(mpp, vecs);
> > > >
> > > > dm_flush_map(mpp->alias,
> > DEFAULT_TARGET);
> > > >
> > > > if
> > (!dm_map_present(mapname))
> > > >
> > > > return 0;
> > > >
> > > > if (dm_type(mapname, type) <= 0)
> > > >
> > > > return 1;
> > > >
> > > > if (dm_remove_partmaps(mapname))
> > > >
> > > > return 1;
> > > >
> > > > if (dm_get_opencount(mapname)) {
> > > >
> > > > condlog(2, "%s: map in use", mapname);
> > > >
> > > > return 1;
> > > >
> > > > }
> > > >
> > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > >
> > > > if (r) {
> > > >
> > > > condlog(4, "multipath map %s removed",
> > mapname);
> > > >
> > > > return 0;
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > > orphan_paths(vecs->pathvec,
> mpp);
> > > >
> > > > remove_map(mpp, vecs,
> > stop_waiter_thread,
> > > 1);
> > > >
> > > > Is removing this below line, the right step to stop
> removing
> > the
> > > device ?
> > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > >
> > > > Regards,
> > > >
> > > > Tejaswini
> > > >
> > > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > > > <[1][2][3]tejaswinipoluri3@gmail.com> wrote:
> > > >
> > > > Thanks a lot Ben for the quick and detailed reply. I
> have
> > been
> > > > struggling to understand and conclude the issues with
> > multipath
> > > as I am
> > > > the only one working from my team. Your inputs help
> me a
> > lot.
> > > Thanks
> > > > again.
> > > > Regards,
> > > > Tejaswini
> > > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > > > <[2][3][4]bmarzins@redhat.com> wrote:
> > > >
> > > > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini
> > Poluri
> > > wrote:
> > > > > Hii Ben,
> > > > >
> > > > > We are testing multipathd tools with all the
> > possible
> > > options and
> > > > the
> > > > > following fails.
> > > > >
> > > > > Case 1 : remove and add map.
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > name sysfs uuid
> > > > > dmpath0 dm-0 1IET_00010001
> > > > > root@x86-generic-64:~# multipathd -k'remove
> map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > root@x86-generic-64:~# multipathd -k'add map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > root@x86-generic-64:~#
> > > > > Once a map is removed, we are able to add it
> only
> > using
> > > > #multipath
> > > > > command and not using multipathd tools.
> > > >
> > > > It is working the way it was designed, but possibly
> it
> > would
> > > make
> > > > sense
> > > > to change the design. The "remove map" command, not
> > only stops
> > > > multipathd from monitoring the multipath device,
> but it
> > removes
> > > it
> > > > from
> > > > the system as well. The "add map" command makes
> > multipath
> > > monitor an
> > > > already existing multipath device that in wasn't
> > previously
> > > > monitoring.
> > > > These commands do this for historical reasons.
> > multipathd
> > > wasn't
> > > > originally in charge of creating multipath devices,
> > multipath
> > > was.
> > > > Once
> > > > it had created the device, it ran
> > > >
> > > > multipathd -k"add map <MAP>"
> > > >
> > > > to make multipathd start monitoring it. However
> things
> > haven't
> > > worked
> > > > this way since RHEL4, so possibly "add map" should
> > actually
> > > create the
> > > > device if it doesn't currently exist.
> > > > > Case 2 : Active paths test case
> > > > > # while true ; do sleep 3 ; multipathd
> -k'remove
> > path sdb'
> > > ;
> > > > multipathd
> > > > > -k'add path sdb' ; multipathd -k'show maps
> status'
> > ; done
> > > > > ok
> > > > > ok
> > > > > name failback queueing paths dm-st
> > > > > dmpath0 - - 1 active // It should be 2.
> > > >
> > > > This is simply a timing issue. What you are seeing
> it
> > the
> > > number of
> > > > active paths. These are paths that the kernel can
> use.
> > The
> > > "add path"
> > > > command doesn't update the kernel state. This
> happens
> > later in
> > > > response
> > > > to the kernel reloading the device table. So, in a
> > second or
> > > two, this
> > > > will say 2, as expected.
> > > >
> > > > > We would like to know if the test cases are
> valid
> > and if
> > > these
> > > > are bugs or
> > > > > any design issues.
> > > > >
> > > > > Case 3 : Fail path and reinstate path
> > > > > root@x86-generic-64:~# multipathd -k"fail path
> > sdc";
> > > multipathd
> > > > > -k'reinstate path sdc'; multipathd -k"show
> paths";
> > > > > > [ 3962.708523] device-mapper: multipath:
> > Failing path
> > > 8:32.
> > > > > > ok
> > > > > > ok
> > > > > > hcil dev dev_t pri dm_st chk_st
> > next_check
> > > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> > ..........
> > > 1/20
> > > > <==CHECK
> > > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> > XX........
> > > 4/20
> > > > > sdc path becomes [active][ready] only after the
> > polling
> > > interval
> > > > but not
> > > > > immediately after the reinstate path command.
> > > > > You have answered that this is a design issue.
> But
> > we have
> > > heard
> > > > from our
> > > > > test team that the same test case works in
> RHEL6.
> > Did you
> > > observe
> > > > it?
> > > > > I am also finding that the test cases fail
> because
> > we are
> > > trying
> > > > to do
> > > > > multiple commands at one shot. Please share
> your
> > thoughts
> > > so
> > > > that it
> > > > > could help me in debugging the issues further.
> > > > >
> > > >
> > > > It's totally possible that the checker state is
> > immediately
> > > updated in
> > > > RHEL6. Like I said before, what it currently does,
> > although
> > > correct,
> > > > is confusing, and perhaps we need a different
> checker
> > state for
> > > paths
> > > > where the "fail path" command has been used.
> > > >
> > > > -Ben
> > > > > Regards,
> > > > > Tejaswini
> > > > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini
> Poluri
> > > > > <[1][3][4][5]tejaswinipoluri3@gmail.com>
> wrote:
> > > > >
> > > > > Thanks a lot Ben. I will look into it more.
> > > > > On Mon, May 18, 2015 at 9:57 PM, Benjamin
> > Marzinski
> > > > > <[2][4][5][6]bmarzins@redhat.com> wrote:
> > > > >
> > > > > On Mon, May 18, 2015 at 02:09:27PM +0530,
> > Tejaswini
> > > Poluri
> > > > wrote:
> > > > > > Hii,
> > > > > > We are trying to test multipath setup
> in
> > our
> > > target and
> > > > tried the
> > > > > various
> > > > > > commands of multipathd demaon and we
> find
> > the
> > > following
> > > > error:
> > > > > > root@x86-generic-64:~# multipathd
> -k"fail
> > path
> > > sdc";
> > > > multipathd
> > > > > > -k'reinstate path
> > > > > > sdc'; multipathd -k"show paths";
> > > > > > [ 3962.708523] device-mapper:
> multipath:
> > Failing
> > > > path 8:32.
> > > > > > ok
> > > > > > ok
> > > > > > hcil dev dev_t pri dm_st chk_st
> > next_check
> > > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> > ..........
> > > 1/20
> > > > <<<===
> > > > > CHECK
> > > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> > XX........
> > > 4/20
> > > > > > sdc path becomes [active][ready] only
> > after the
> > > polling
> > > > interval
> > > > > but not
> > > > > > immediately after the reinstate path
> > command.
> > > > > > I am observing this in latest
> multipath
> > tools in
> > > ubuntu
> > > > machine
> > > > > as well.
> > > > > > Please let me know if its a known
> issue or
> > if I
> > > am doing
> > > > > something wrong.
> > > > > > Regards.
> > > > > > Tejaswini
> > > > >
> > > > > the reinstate command is supposed to
> reinstate
> > the
> > > device
> > > > with the
> > > > > kernel, and it does that. The checker state
> > doesn't
> > > change
> > > > until the
> > > > > next time that the path is checked. I
> agree
> > that it's
> > > odd
> > > > that the
> > > > > check state switches to faulty as soon as
> you
> > fail the
> > > path,
> > > > but it
> > > > > doesn't switch back until the next check
> after
> > you
> > > reinistate
> > > > it.
> > > > >
> > > > > The issue is that multipathd needs to
> override
> > the
> > > checker
> > > > output,
> > > > > so that a failed path won't be immeditately
> > > reinstated. Once
> > > > the
> > > > > path comes back, multipathd wants to
> record the
> > switch
> > > in the
> > > > checker
> > > > > thread, so that it can refresh path
> information
> > what
> > > wasn't
> > > > > automatically done when the path was
> > reinstated.
> > > However, it
> > > > may make
> > > > > more sense to have a different checker
> state
> > for when
> > > the
> > > > device is
> > > > > in the failed state, so that it's obvious
> that
> > the
> > > checker
> > > > state is
> > > > > being overruled.
> > > > >
> > > > > -Ben
> > > > >
> > > > > > --
> > > > > > dm-devel mailing list
> > > > > > [3][5][6][7]dm-devel@redhat.com
> > > > > >
> > > [4][6][7][8]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > --
> > > > > dm-devel mailing list
> > > > > [5][7][8][9]dm-devel@redhat.com
> > > > >
> > > [6][8][9][10]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1. mailto:[9][10][11]
> tejaswinipoluri3@gmail.com
> > > > > 2. mailto:[10][11][12]bmarzins@redhat.com
> > > > > 3. mailto:[11][12][13]dm-devel@redhat.com
> > > > > 4.
> > > [12][13][14]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 5. mailto:[13][14][15]dm-devel@redhat.com
> > > > > 6.
> > > [14][15][16]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[16][17]tejaswinipoluri3@gmail.com
> > > > 2. mailto:[17][18]bmarzins@redhat.com
> > > > 3. mailto:[18][19]tejaswinipoluri3@gmail.com
> > > > 4. mailto:[19][20]bmarzins@redhat.com
> > > > 5. mailto:[20][21]dm-devel@redhat.com
> > > > 6. [21][22]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 7. mailto:[22][23]dm-devel@redhat.com
> > > > 8. [23][24]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 9. mailto:[24][25]tejaswinipoluri3@gmail.com
> > > > 10. mailto:[25][26]bmarzins@redhat.com
> > > > 11. mailto:[26][27]dm-devel@redhat.com
> > > > 12. [27][28]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 13. mailto:[28][29]dm-devel@redhat.com
> > > > 14. [29][30]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[31]bmarzins@redhat.com
> > > 2. mailto:[32]tejaswinipoluri3@gmail.com
> > > 3. mailto:[33]bmarzins@redhat.com
> > > 4. mailto:[34]tejaswinipoluri3@gmail.com
> > > 5. mailto:[35]bmarzins@redhat.com
> > > 6. mailto:[36]dm-devel@redhat.com
> > > 7. [37]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 8. mailto:[38]dm-devel@redhat.com
> > > 9. [39]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 10. mailto:[40]tejaswinipoluri3@gmail.com
> > > 11. mailto:[41]bmarzins@redhat.com
> > > 12. mailto:[42]dm-devel@redhat.com
> > > 13. [43]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 14. mailto:[44]dm-devel@redhat.com
> > > 15. [45]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 16. mailto:[46]tejaswinipoluri3@gmail.com
> > > 17. mailto:[47]bmarzins@redhat.com
> > > 18. mailto:[48]tejaswinipoluri3@gmail.com
> > > 19. mailto:[49]bmarzins@redhat.com
> > > 20. mailto:[50]dm-devel@redhat.com
> > > 21. [51]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 22. mailto:[52]dm-devel@redhat.com
> > > 23. [53]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 24. mailto:[54]tejaswinipoluri3@gmail.com
> > > 25. mailto:[55]bmarzins@redhat.com
> > > 26. mailto:[56]dm-devel@redhat.com
> > > 27. [57]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 28. mailto:[58]dm-devel@redhat.com
> > > 29. [59]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:bmarzins@redhat.com
> > 2. mailto:bmarzins@redhat.com
> > 3. mailto:tejaswinipoluri3@gmail.com
> > 4. mailto:bmarzins@redhat.com
> > 5. mailto:tejaswinipoluri3@gmail.com
> > 6. mailto:bmarzins@redhat.com
> > 7. mailto:dm-devel@redhat.com
> > 8. https://www.redhat.com/mailman/listinfo/dm-devel
> > 9. mailto:dm-devel@redhat.com
> > 10. https://www.redhat.com/mailman/listinfo/dm-devel
> > 11. mailto:tejaswinipoluri3@gmail.com
> > 12. mailto:bmarzins@redhat.com
> > 13. mailto:dm-devel@redhat.com
> > 14. https://www.redhat.com/mailman/listinfo/dm-devel
> > 15. mailto:dm-devel@redhat.com
> > 16. https://www.redhat.com/mailman/listinfo/dm-devel
> > 17. mailto:tejaswinipoluri3@gmail.com
> > 18. mailto:bmarzins@redhat.com
> > 19. mailto:tejaswinipoluri3@gmail.com
> > 20. mailto:bmarzins@redhat.com
> > 21. mailto:dm-devel@redhat.com
> > 22. https://www.redhat.com/mailman/listinfo/dm-devel
> > 23. mailto:dm-devel@redhat.com
> > 24. https://www.redhat.com/mailman/listinfo/dm-devel
> > 25. mailto:tejaswinipoluri3@gmail.com
> > 26. mailto:bmarzins@redhat.com
> > 27. mailto:dm-devel@redhat.com
> > 28. https://www.redhat.com/mailman/listinfo/dm-devel
> > 29. mailto:dm-devel@redhat.com
> > 30. https://www.redhat.com/mailman/listinfo/dm-devel
> > 31. mailto:bmarzins@redhat.com
> > 32. mailto:tejaswinipoluri3@gmail.com
> > 33. mailto:bmarzins@redhat.com
> > 34. mailto:tejaswinipoluri3@gmail.com
> > 35. mailto:bmarzins@redhat.com
> > 36. mailto:dm-devel@redhat.com
> > 37. https://www.redhat.com/mailman/listinfo/dm-devel
> > 38. mailto:dm-devel@redhat.com
> > 39. https://www.redhat.com/mailman/listinfo/dm-devel
> > 40. mailto:tejaswinipoluri3@gmail.com
> > 41. mailto:bmarzins@redhat.com
> > 42. mailto:dm-devel@redhat.com
> > 43. https://www.redhat.com/mailman/listinfo/dm-devel
> > 44. mailto:dm-devel@redhat.com
> > 45. https://www.redhat.com/mailman/listinfo/dm-devel
> > 46. mailto:tejaswinipoluri3@gmail.com
> > 47. mailto:bmarzins@redhat.com
> > 48. mailto:tejaswinipoluri3@gmail.com
> > 49. mailto:bmarzins@redhat.com
> > 50. mailto:dm-devel@redhat.com
> > 51. https://www.redhat.com/mailman/listinfo/dm-devel
> > 52. mailto:dm-devel@redhat.com
> > 53. https://www.redhat.com/mailman/listinfo/dm-devel
> > 54. mailto:tejaswinipoluri3@gmail.com
> > 55. mailto:bmarzins@redhat.com
> > 56. mailto:dm-devel@redhat.com
> > 57. https://www.redhat.com/mailman/listinfo/dm-devel
> > 58. mailto:dm-devel@redhat.com
> > 59. https://www.redhat.com/mailman/listinfo/dm-devel
>
[-- Attachment #1.2: Type: text/html, Size: 47995 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-06-30 5:52 ` Tejaswini Poluri
@ 2015-07-06 17:45 ` Benjamin Marzinski
2015-07-08 12:01 ` Tejaswini Poluri
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Marzinski @ 2015-07-06 17:45 UTC (permalink / raw)
To: Tejaswini Poluri; +Cc: device-mapper development
On Tue, Jun 30, 2015 at 11:22:37AM +0530, Tejaswini Poluri wrote:
> Thanks Ben. So should I push the code to the upstream and get an approval?
> Regards,
Yes. Thanks!
-Ben
> Tejaswini
> On Tue, Jun 30, 2015 at 12:50 AM, Benjamin Marzinski
> <[1]bmarzins@redhat.com> wrote:
>
> On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri wrote:
> > Yes I agree that having the same code in both cli_add_map() and
> ev_add_map
> > is not necessary. Hence I would suggest removing get_refwwid() code
> from
> > ev_add_map as it is not being used by anyone.
> >
> > ev_add_map(param, NULL, vecs) would create the multipath device by
> using
> > the get_refwwid() code and but all the functions above it like
> > (dm_get_minor, dm_get_major and dm_mapname) would fail and it
> wouldn't
> > enter any of the other code in ev_add_map like
> > 1.dm_map_present,
> > 2.add_map_without_path
> > 3. sync_map_state
> > which are responsible for registering the map and displaying it.
> >
> > So, I think moving the below code from ev_add_map to cli_add_map
> should be
> > a good idea right.
> >
> > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > >
> > > if (refwwid) {
> > > r = coalesce_paths(vecs, NULL, refwwid,0);
> > > dm_lib_release();
> > > }
> > What do u think?
>
> I agree. We aren't using the code in ev_add_map, so it's presence there
> is simply confusing.
>
> -Ben
> >
> > Regards,
> > Tejaswini
> > On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> > <[1][2]bmarzins@redhat.com> wrote:
> >
> > On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:
> > > Hi Ben,
> > >
> > > This is regarding the add map issue I have been discussing.
> Posting
> > the
> > > issue again to remind.
> > >
> > > Case 1 : remove and add map.
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > name sysfs uuid
> > > dmpath0 dm-0 1IET_00010001
> > > root@x86-generic-64:~# multipathd -k'remove map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > ok
> > > root@x86-generic-64:~# multipathd -k'show maps'
> > > root@x86-generic-64:~#
> > > Once a map is removed, we are able to add it only using
> #multipath
> > > command and not using multipathd tools.
> > >
> > > I have fixed the problem with two approaches. I would like
> you to
> > review
> > > the same.
> > > Patch1 : By making 'remove map dmpath0' to remove only the
> map and
> > not the
> > > device. I have added extra functions discard_map and
> dm_remove_map
> > so as
> > > to not interfere with the existing code.
> > >
> > > Patch 2: The approach you have suggested.By getting wwid
> from the
> > mapname
> > > and doing coalesce_paths. I have just moved the following
> code in
> > > ev_add_map to cli_add_map.
> >
> > This is the general idea we'd like to go with. However, looking
> at the
> > latest upstream code, I don't think you should pull code in from
> > ev_add_map() to cli_add_map() like your patch does. cli_add_map()
> > already calls ev_add_map(), and ev_add_map() is certainly able to
> add
> > the map if it doesn't already exist.
> >
> > You would just need to call it with
> >
> > ev_add_map(param, NULL, vecs);
> >
> > and ev_add_map() will happily create you a new multipath device.
> All
> > you need to do is make sure that all the functions that
> ev_add_map()
> > calls with alias can accept a NULL value there.
> >
> > This might not be the best way to go about this, however. It
> turns out
> > that right now, even though ev_add_map() technically has the
> ability to
> > create new maps, nothing currently uses it, and it really doesn't
> make
> > sense for it to be there. Instead of just copying that code, you
> could
> > pull the map creation code out of ev_add_map() and add it to
> > cli_add_map(), for those situations where the requested device
> doesn't
> > already exist.
> >
> > But having the code in both cli_add_map() and ev_add_map() when
> one
> > already calls the other doesn't seem necessary.
> >
> > -Ben
> >
> > >
> > > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > >
> > > if (refwwid) {
> > > r = coalesce_paths(vecs, NULL, refwwid,0);
> > > dm_lib_release();
> > > }
> > >
> > > changed dev to param.
> > >
> > > I have tested the same in all 3 versions -0.4.8, 0.4.9 and
> 0.5.0.
> > It would
> > > be great if you can review the same so that it doesn't cause
> any
> > extra
> > > side effects.
> > > I guess Patch2 is the way u have suggested me in the
> previous mail.
> > Please
> > > review it and share your views.
> > > Regards,
> > > Tejaswini
> > > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > > <[1][2][3]bmarzins@redhat.com> wrote:
> > >
> > > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri
> wrote:
> > > >
> > > > > We are testing multipathd tools with all the
> possible
> > options
> > > and the
> > > > > following fails.
> > > > >
> > > > > Case 1 : remove and add map.
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > name sysfs uuid
> > > > > dmpath0 dm-0 1IET_00010001
> > > > > root@x86-generic-64:~# multipathd -k'remove map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~# multipathd -k'add map
> dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~#
> > > > > Once a map is removed, we are able to add it
> only using
> > > #multipath
> > > > > command and not using multipathd tools.
> > > >
> > > > It is working the way it was designed, but possibly
> it would
> > make
> > > sense
> > > > to change the design.
> > > >
> > > > You have mentioned that it would make sense to change
> the
> > design to
> > > add
> > > > map. Are there plans to change the design ?
> > > > I am trying to understand the code flow to change the
> > design. Can
> > > you
> > > > guide me if we should stop removing the device from
> in the
> > remove
> > > map code
> > > > flow or start adding the device and the map in the
> add map
> > code
> > > flow.
> > > >
> > > > have tried to understand the remove map code flow of
> > multipathd in
> > > 0.4.8
> > > > code.
> > >
> > > I think that we want multipath to actually remove the map
> > (instead of
> > > just not monitoring it) when you call "remove map <map>".
> We just
> > want
> > > "add map <map>" to try to create the map if it doesn't
> exist. To
> > do
> > > that, you would need to first firgure out what WWID is
> associated
> > with
> > > <map>. Presumably, <map> could either be an alias, wwid,
> or even
> > the
> > > name of a path in the map. Once you found the map, you
> would have
> > to
> > > call the code to create the map.
> > >
> > > Also, to answer your IRC question, no the 0.4.8 code is
> not still
> > being
> > > developed upstream. All upstream patches only go against
> the
> > current
> > > head. There are no other upstream branches.
> > >
> > > -Ben
> > > >
> > > > ev_remove_map (char * devname, struct vectors * vecs)
> > > >
> > > > flush_map(mpp, vecs);
> > > >
> > > > dm_flush_map(mpp->alias,
> > DEFAULT_TARGET);
> > > >
> > > > if
> > (!dm_map_present(mapname))
> > > >
> > > > return 0;
> > > >
> > > > if (dm_type(mapname, type) <= 0)
> > > >
> > > > return 1;
> > > >
> > > > if (dm_remove_partmaps(mapname))
> > > >
> > > > return 1;
> > > >
> > > > if (dm_get_opencount(mapname)) {
> > > >
> > > > condlog(2, "%s: map in use", mapname);
> > > >
> > > > return 1;
> > > >
> > > > }
> > > >
> > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > >
> > > > if (r) {
> > > >
> > > > condlog(4, "multipath map %s removed",
> > mapname);
> > > >
> > > > return
> 0;
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > > orphan_paths(vecs->pathvec,
> mpp);
> > > >
> > > > remove_map(mpp, vecs,
> > stop_waiter_thread,
> > > 1);
> > > >
> > > > Is removing this below line, the right step to stop
> removing
> > the
> > > device ?
> > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > >
> > > > Regards,
> > > >
> > > > Tejaswini
> > > >
> > > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > > > <[1][2][3][4]tejaswinipoluri3@gmail.com> wrote:
> > > >
> > > > Thanks a lot Ben for the quick and detailed reply.
> I have
> > been
> > > > struggling to understand and conclude the issues
> with
> > multipath
> > > as I am
> > > > the only one working from my team. Your inputs help
> me a
> > lot.
> > > Thanks
> > > > again.
> > > > Regards,
> > > > Tejaswini
> > > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski
> > > > <[2][3][4][5]bmarzins@redhat.com> wrote:
> > > >
> > > > On Fri, Jun 05, 2015 at 02:31:20PM +0530,
> Tejaswini
> > Poluri
> > > wrote:
> > > > > Hii Ben,
> > > > >
> > > > > We are testing multipathd tools with all the
> > possible
> > > options and
> > > > the
> > > > > following fails.
> > > > >
> > > > > Case 1 : remove and add map.
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > name sysfs uuid
> > > > > dmpath0 dm-0 1IET_00010001
> > > > > root@x86-generic-64:~# multipathd -k'remove
> map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > root@x86-generic-64:~# multipathd -k'add map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > root@x86-generic-64:~#
> > > > > Once a map is removed, we are able to add it
> only
> > using
> > > > #multipath
> > > > > command and not using multipathd tools.
> > > >
> > > > It is working the way it was designed, but
> possibly it
> > would
> > > make
> > > > sense
> > > > to change the design. The "remove map" command,
> not
> > only stops
> > > > multipathd from monitoring the multipath device,
> but it
> > removes
> > > it
> > > > from
> > > > the system as well. The "add map" command makes
> > multipath
> > > monitor an
> > > > already existing multipath device that in wasn't
> > previously
> > > > monitoring.
> > > > These commands do this for historical reasons.
> > multipathd
> > > wasn't
> > > > originally in charge of creating multipath
> devices,
> > multipath
> > > was.
> > > > Once
> > > > it had created the device, it ran
> > > >
> > > > multipathd -k"add map <MAP>"
> > > >
> > > > to make multipathd start monitoring it. However
> things
> > haven't
> > > worked
> > > > this way since RHEL4, so possibly "add map"
> should
> > actually
> > > create the
> > > > device if it doesn't currently exist.
> > > > > Case 2 : Active paths test case
> > > > > # while true ; do sleep 3 ; multipathd
> -k'remove
> > path sdb'
> > > ;
> > > > multipathd
> > > > > -k'add path sdb' ; multipathd -k'show maps
> status'
> > ; done
> > > > > ok
> > > > > ok
> > > > > name failback queueing paths dm-st
> > > > > dmpath0 - - 1 active // It should be 2.
> > > >
> > > > This is simply a timing issue. What you are
> seeing it
> > the
> > > number of
> > > > active paths. These are paths that the kernel
> can use.
> > The
> > > "add path"
> > > > command doesn't update the kernel state. This
> happens
> > later in
> > > > response
> > > > to the kernel reloading the device table. So, in
> a
> > second or
> > > two, this
> > > > will say 2, as expected.
> > > >
> > > > > We would like to know if the test cases are
> valid
> > and if
> > > these
> > > > are bugs or
> > > > > any design issues.
> > > > >
> > > > > Case 3 : Fail path and reinstate path
> > > > > root@x86-generic-64:~# multipathd -k"fail
> path
> > sdc";
> > > multipathd
> > > > > -k'reinstate path sdc'; multipathd -k"show
> paths";
> > > > > > [ 3962.708523] device-mapper:
> multipath:
> > Failing path
> > > 8:32.
> > > > > > ok
> > > > > > ok
> > > > > > hcil dev dev_t pri dm_st chk_st
> > next_check
> > > > > > 4:0:0:1 sdc 8:32 1 [active][faulty]
> > ..........
> > > 1/20
> > > > <==CHECK
> > > > > > 5:0:0:1 sdd 8:48 1 [active][ready]
> > XX........
> > > 4/20
> > > > > sdc path becomes [active][ready] only after
> the
> > polling
> > > interval
> > > > but not
> > > > > immediately after the reinstate path
> command.
> > > > > You have answered that this is a design
> issue. But
> > we have
> > > heard
> > > > from our
> > > > > test team that the same test case works in
> RHEL6.
> > Did you
> > > observe
> > > > it?
> > > > > I am also finding that the test cases fail
> because
> > we are
> > > trying
> > > > to do
> > > > > multiple commands at one shot. Please share
> your
> > thoughts
> > > so
> > > > that it
> > > > > could help me in debugging the issues
> further.
> > > > >
> > > >
> > > > It's totally possible that the checker state is
> > immediately
> > > updated in
> > > > RHEL6. Like I said before, what it currently
> does,
> > although
> > > correct,
> > > > is confusing, and perhaps we need a different
> checker
> > state for
> > > paths
> > > > where the "fail path" command has been used.
> > > >
> > > > -Ben
> > > > > Regards,
> > > > > Tejaswini
> > > > > On Tue, May 19, 2015 at 5:37 PM, Tejaswini
> Poluri
> > > > > <[1][3][4][5][6]tejaswinipoluri3@gmail.com>
> wrote:
> > > > >
> > > > > Thanks a lot Ben. I will look into it
> more.
> > > > > On Mon, May 18, 2015 at 9:57 PM, Benjamin
> > Marzinski
> > > > > <[2][4][5][6][7]bmarzins@redhat.com>
> wrote:
> > > > >
> > > > > On Mon, May 18, 2015 at 02:09:27PM
> +0530,
> > Tejaswini
> > > Poluri
> > > > wrote:
> > > > > > Hii,
> > > > > > We are trying to test multipath
> setup in
> > our
> > > target and
> > > > tried the
> > > > > various
> > > > > > commands of multipathd demaon and
> we find
> > the
> > > following
> > > > error:
> > > > > > root@x86-generic-64:~# multipathd
> -k"fail
> > path
> > > sdc";
> > > > multipathd
> > > > > > -k'reinstate path
> > > > > > sdc'; multipathd -k"show paths";
> > > > > > [ 3962.708523] device-mapper:
> multipath:
> > Failing
> > > > path 8:32.
> > > > > > ok
> > > > > > ok
> > > > > > hcil dev dev_t pri dm_st
> chk_st
> > next_check
> > > > > > 4:0:0:1 sdc 8:32 1
> [active][faulty]
> > ..........
> > > 1/20
> > > > <<<===
> > > > > CHECK
> > > > > > 5:0:0:1 sdd 8:48 1
> [active][ready]
> > XX........
> > > 4/20
> > > > > > sdc path becomes [active][ready]
> only
> > after the
> > > polling
> > > > interval
> > > > > but not
> > > > > > immediately after the reinstate
> path
> > command.
> > > > > > I am observing this in latest
> multipath
> > tools in
> > > ubuntu
> > > > machine
> > > > > as well.
> > > > > > Please let me know if its a known
> issue or
> > if I
> > > am doing
> > > > > something wrong.
> > > > > > Regards.
> > > > > > Tejaswini
> > > > >
> > > > > the reinstate command is supposed to
> reinstate
> > the
> > > device
> > > > with the
> > > > > kernel, and it does that. The checker
> state
> > doesn't
> > > change
> > > > until the
> > > > > next time that the path is checked. I
> agree
> > that it's
> > > odd
> > > > that the
> > > > > check state switches to faulty as soon
> as you
> > fail the
> > > path,
> > > > but it
> > > > > doesn't switch back until the next check
> after
> > you
> > > reinistate
> > > > it.
> > > > >
> > > > > The issue is that multipathd needs to
> override
> > the
> > > checker
> > > > output,
> > > > > so that a failed path won't be
> immeditately
> > > reinstated. Once
> > > > the
> > > > > path comes back, multipathd wants to
> record the
> > switch
> > > in the
> > > > checker
> > > > > thread, so that it can refresh path
> information
> > what
> > > wasn't
> > > > > automatically done when the path was
> > reinstated.
> > > However, it
> > > > may make
> > > > > more sense to have a different checker
> state
> > for when
> > > the
> > > > device is
> > > > > in the failed state, so that it's
> obvious that
> > the
> > > checker
> > > > state is
> > > > > being overruled.
> > > > >
> > > > > -Ben
> > > > >
> > > > > > --
> > > > > > dm-devel mailing list
> > > > > > [3][5][6][7][8]dm-devel@redhat.com
> > > > > >
> > >
> [4][6][7][8][9]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > --
> > > > > dm-devel mailing list
> > > > > [5][7][8][9][10]dm-devel@redhat.com
> > > > >
> > >
> [6][8][9][10][11]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1.
> mailto:[9][10][11][12]tejaswinipoluri3@gmail.com
> > > > > 2.
> mailto:[10][11][12][13]bmarzins@redhat.com
> > > > > 3.
> mailto:[11][12][13][14]dm-devel@redhat.com
> > > > > 4.
> > >
> [12][13][14][15]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 5.
> mailto:[13][14][15][16]dm-devel@redhat.com
> > > > > 6.
> > >
> [14][15][16][17]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[16][17][18]tejaswinipoluri3@gmail.com
> > > > 2. mailto:[17][18][19]bmarzins@redhat.com
> > > > 3. mailto:[18][19][20]tejaswinipoluri3@gmail.com
> > > > 4. mailto:[19][20][21]bmarzins@redhat.com
> > > > 5. mailto:[20][21][22]dm-devel@redhat.com
> > > > 6.
> [21][22][23]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 7. mailto:[22][23][24]dm-devel@redhat.com
> > > > 8.
> [23][24][25]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 9. mailto:[24][25][26]tejaswinipoluri3@gmail.com
> > > > 10. mailto:[25][26][27]bmarzins@redhat.com
> > > > 11. mailto:[26][27][28]dm-devel@redhat.com
> > > > 12.
> [27][28][29]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 13. mailto:[28][29][30]dm-devel@redhat.com
> > > > 14.
> [29][30][31]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[31][32]bmarzins@redhat.com
> > > 2. mailto:[32][33]tejaswinipoluri3@gmail.com
> > > 3. mailto:[33][34]bmarzins@redhat.com
> > > 4. mailto:[34][35]tejaswinipoluri3@gmail.com
> > > 5. mailto:[35][36]bmarzins@redhat.com
> > > 6. mailto:[36][37]dm-devel@redhat.com
> > > 7. [37][38]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 8. mailto:[38][39]dm-devel@redhat.com
> > > 9. [39][40]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 10. mailto:[40][41]tejaswinipoluri3@gmail.com
> > > 11. mailto:[41][42]bmarzins@redhat.com
> > > 12. mailto:[42][43]dm-devel@redhat.com
> > > 13. [43][44]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 14. mailto:[44][45]dm-devel@redhat.com
> > > 15. [45][46]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 16. mailto:[46][47]tejaswinipoluri3@gmail.com
> > > 17. mailto:[47][48]bmarzins@redhat.com
> > > 18. mailto:[48][49]tejaswinipoluri3@gmail.com
> > > 19. mailto:[49][50]bmarzins@redhat.com
> > > 20. mailto:[50][51]dm-devel@redhat.com
> > > 21. [51][52]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 22. mailto:[52][53]dm-devel@redhat.com
> > > 23. [53][54]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 24. mailto:[54][55]tejaswinipoluri3@gmail.com
> > > 25. mailto:[55][56]bmarzins@redhat.com
> > > 26. mailto:[56][57]dm-devel@redhat.com
> > > 27. [57][58]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 28. mailto:[58][59]dm-devel@redhat.com
> > > 29. [59][60]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:[61]bmarzins@redhat.com
> > 2. mailto:[62]bmarzins@redhat.com
> > 3. mailto:[63]tejaswinipoluri3@gmail.com
> > 4. mailto:[64]bmarzins@redhat.com
> > 5. mailto:[65]tejaswinipoluri3@gmail.com
> > 6. mailto:[66]bmarzins@redhat.com
> > 7. mailto:[67]dm-devel@redhat.com
> > 8. [68]https://www.redhat.com/mailman/listinfo/dm-devel
> > 9. mailto:[69]dm-devel@redhat.com
> > 10. [70]https://www.redhat.com/mailman/listinfo/dm-devel
> > 11. mailto:[71]tejaswinipoluri3@gmail.com
> > 12. mailto:[72]bmarzins@redhat.com
> > 13. mailto:[73]dm-devel@redhat.com
> > 14. [74]https://www.redhat.com/mailman/listinfo/dm-devel
> > 15. mailto:[75]dm-devel@redhat.com
> > 16. [76]https://www.redhat.com/mailman/listinfo/dm-devel
> > 17. mailto:[77]tejaswinipoluri3@gmail.com
> > 18. mailto:[78]bmarzins@redhat.com
> > 19. mailto:[79]tejaswinipoluri3@gmail.com
> > 20. mailto:[80]bmarzins@redhat.com
> > 21. mailto:[81]dm-devel@redhat.com
> > 22. [82]https://www.redhat.com/mailman/listinfo/dm-devel
> > 23. mailto:[83]dm-devel@redhat.com
> > 24. [84]https://www.redhat.com/mailman/listinfo/dm-devel
> > 25. mailto:[85]tejaswinipoluri3@gmail.com
> > 26. mailto:[86]bmarzins@redhat.com
> > 27. mailto:[87]dm-devel@redhat.com
> > 28. [88]https://www.redhat.com/mailman/listinfo/dm-devel
> > 29. mailto:[89]dm-devel@redhat.com
> > 30. [90]https://www.redhat.com/mailman/listinfo/dm-devel
> > 31. mailto:[91]bmarzins@redhat.com
> > 32. mailto:[92]tejaswinipoluri3@gmail.com
> > 33. mailto:[93]bmarzins@redhat.com
> > 34. mailto:[94]tejaswinipoluri3@gmail.com
> > 35. mailto:[95]bmarzins@redhat.com
> > 36. mailto:[96]dm-devel@redhat.com
> > 37. [97]https://www.redhat.com/mailman/listinfo/dm-devel
> > 38. mailto:[98]dm-devel@redhat.com
> > 39. [99]https://www.redhat.com/mailman/listinfo/dm-devel
> > 40. mailto:[100]tejaswinipoluri3@gmail.com
> > 41. mailto:[101]bmarzins@redhat.com
> > 42. mailto:[102]dm-devel@redhat.com
> > 43. [103]https://www.redhat.com/mailman/listinfo/dm-devel
> > 44. mailto:[104]dm-devel@redhat.com
> > 45. [105]https://www.redhat.com/mailman/listinfo/dm-devel
> > 46. mailto:[106]tejaswinipoluri3@gmail.com
> > 47. mailto:[107]bmarzins@redhat.com
> > 48. mailto:[108]tejaswinipoluri3@gmail.com
> > 49. mailto:[109]bmarzins@redhat.com
> > 50. mailto:[110]dm-devel@redhat.com
> > 51. [111]https://www.redhat.com/mailman/listinfo/dm-devel
> > 52. mailto:[112]dm-devel@redhat.com
> > 53. [113]https://www.redhat.com/mailman/listinfo/dm-devel
> > 54. mailto:[114]tejaswinipoluri3@gmail.com
> > 55. mailto:[115]bmarzins@redhat.com
> > 56. mailto:[116]dm-devel@redhat.com
> > 57. [117]https://www.redhat.com/mailman/listinfo/dm-devel
> > 58. mailto:[118]dm-devel@redhat.com
> > 59. [119]https://www.redhat.com/mailman/listinfo/dm-devel
>
> References
>
> Visible links
> 1. mailto:bmarzins@redhat.com
> 2. mailto:bmarzins@redhat.com
> 3. mailto:bmarzins@redhat.com
> 4. mailto:tejaswinipoluri3@gmail.com
> 5. mailto:bmarzins@redhat.com
> 6. mailto:tejaswinipoluri3@gmail.com
> 7. mailto:bmarzins@redhat.com
> 8. mailto:dm-devel@redhat.com
> 9. https://www.redhat.com/mailman/listinfo/dm-devel
> 10. mailto:dm-devel@redhat.com
> 11. https://www.redhat.com/mailman/listinfo/dm-devel
> 12. mailto:tejaswinipoluri3@gmail.com
> 13. mailto:bmarzins@redhat.com
> 14. mailto:dm-devel@redhat.com
> 15. https://www.redhat.com/mailman/listinfo/dm-devel
> 16. mailto:dm-devel@redhat.com
> 17. https://www.redhat.com/mailman/listinfo/dm-devel
> 18. mailto:tejaswinipoluri3@gmail.com
> 19. mailto:bmarzins@redhat.com
> 20. mailto:tejaswinipoluri3@gmail.com
> 21. mailto:bmarzins@redhat.com
> 22. mailto:dm-devel@redhat.com
> 23. https://www.redhat.com/mailman/listinfo/dm-devel
> 24. mailto:dm-devel@redhat.com
> 25. https://www.redhat.com/mailman/listinfo/dm-devel
> 26. mailto:tejaswinipoluri3@gmail.com
> 27. mailto:bmarzins@redhat.com
> 28. mailto:dm-devel@redhat.com
> 29. https://www.redhat.com/mailman/listinfo/dm-devel
> 30. mailto:dm-devel@redhat.com
> 31. https://www.redhat.com/mailman/listinfo/dm-devel
> 32. mailto:bmarzins@redhat.com
> 33. mailto:tejaswinipoluri3@gmail.com
> 34. mailto:bmarzins@redhat.com
> 35. mailto:tejaswinipoluri3@gmail.com
> 36. mailto:bmarzins@redhat.com
> 37. mailto:dm-devel@redhat.com
> 38. https://www.redhat.com/mailman/listinfo/dm-devel
> 39. mailto:dm-devel@redhat.com
> 40. https://www.redhat.com/mailman/listinfo/dm-devel
> 41. mailto:tejaswinipoluri3@gmail.com
> 42. mailto:bmarzins@redhat.com
> 43. mailto:dm-devel@redhat.com
> 44. https://www.redhat.com/mailman/listinfo/dm-devel
> 45. mailto:dm-devel@redhat.com
> 46. https://www.redhat.com/mailman/listinfo/dm-devel
> 47. mailto:tejaswinipoluri3@gmail.com
> 48. mailto:bmarzins@redhat.com
> 49. mailto:tejaswinipoluri3@gmail.com
> 50. mailto:bmarzins@redhat.com
> 51. mailto:dm-devel@redhat.com
> 52. https://www.redhat.com/mailman/listinfo/dm-devel
> 53. mailto:dm-devel@redhat.com
> 54. https://www.redhat.com/mailman/listinfo/dm-devel
> 55. mailto:tejaswinipoluri3@gmail.com
> 56. mailto:bmarzins@redhat.com
> 57. mailto:dm-devel@redhat.com
> 58. https://www.redhat.com/mailman/listinfo/dm-devel
> 59. mailto:dm-devel@redhat.com
> 60. https://www.redhat.com/mailman/listinfo/dm-devel
> 61. mailto:bmarzins@redhat.com
> 62. mailto:bmarzins@redhat.com
> 63. mailto:tejaswinipoluri3@gmail.com
> 64. mailto:bmarzins@redhat.com
> 65. mailto:tejaswinipoluri3@gmail.com
> 66. mailto:bmarzins@redhat.com
> 67. mailto:dm-devel@redhat.com
> 68. https://www.redhat.com/mailman/listinfo/dm-devel
> 69. mailto:dm-devel@redhat.com
> 70. https://www.redhat.com/mailman/listinfo/dm-devel
> 71. mailto:tejaswinipoluri3@gmail.com
> 72. mailto:bmarzins@redhat.com
> 73. mailto:dm-devel@redhat.com
> 74. https://www.redhat.com/mailman/listinfo/dm-devel
> 75. mailto:dm-devel@redhat.com
> 76. https://www.redhat.com/mailman/listinfo/dm-devel
> 77. mailto:tejaswinipoluri3@gmail.com
> 78. mailto:bmarzins@redhat.com
> 79. mailto:tejaswinipoluri3@gmail.com
> 80. mailto:bmarzins@redhat.com
> 81. mailto:dm-devel@redhat.com
> 82. https://www.redhat.com/mailman/listinfo/dm-devel
> 83. mailto:dm-devel@redhat.com
> 84. https://www.redhat.com/mailman/listinfo/dm-devel
> 85. mailto:tejaswinipoluri3@gmail.com
> 86. mailto:bmarzins@redhat.com
> 87. mailto:dm-devel@redhat.com
> 88. https://www.redhat.com/mailman/listinfo/dm-devel
> 89. mailto:dm-devel@redhat.com
> 90. https://www.redhat.com/mailman/listinfo/dm-devel
> 91. mailto:bmarzins@redhat.com
> 92. mailto:tejaswinipoluri3@gmail.com
> 93. mailto:bmarzins@redhat.com
> 94. mailto:tejaswinipoluri3@gmail.com
> 95. mailto:bmarzins@redhat.com
> 96. mailto:dm-devel@redhat.com
> 97. https://www.redhat.com/mailman/listinfo/dm-devel
> 98. mailto:dm-devel@redhat.com
> 99. https://www.redhat.com/mailman/listinfo/dm-devel
> 100. mailto:tejaswinipoluri3@gmail.com
> 101. mailto:bmarzins@redhat.com
> 102. mailto:dm-devel@redhat.com
> 103. https://www.redhat.com/mailman/listinfo/dm-devel
> 104. mailto:dm-devel@redhat.com
> 105. https://www.redhat.com/mailman/listinfo/dm-devel
> 106. mailto:tejaswinipoluri3@gmail.com
> 107. mailto:bmarzins@redhat.com
> 108. mailto:tejaswinipoluri3@gmail.com
> 109. mailto:bmarzins@redhat.com
> 110. mailto:dm-devel@redhat.com
> 111. https://www.redhat.com/mailman/listinfo/dm-devel
> 112. mailto:dm-devel@redhat.com
> 113. https://www.redhat.com/mailman/listinfo/dm-devel
> 114. mailto:tejaswinipoluri3@gmail.com
> 115. mailto:bmarzins@redhat.com
> 116. mailto:dm-devel@redhat.com
> 117. https://www.redhat.com/mailman/listinfo/dm-devel
> 118. mailto:dm-devel@redhat.com
> 119. https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-07-06 17:45 ` Benjamin Marzinski
@ 2015-07-08 12:01 ` Tejaswini Poluri
2015-07-10 16:06 ` Benjamin Marzinski
0 siblings, 1 reply; 11+ messages in thread
From: Tejaswini Poluri @ 2015-07-08 12:01 UTC (permalink / raw)
To: Benjamin Marzinski; +Cc: device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 40613 bytes --]
Thanks a lot.
Can you guide me how to push upstream for the approval. Which branch should
I push to? Any list of testcases I should perform before I could push?
I have created the following two patches. PFA
Regards,
Tejaswini
On Mon, Jul 6, 2015 at 11:15 PM, Benjamin Marzinski <bmarzins@redhat.com>
wrote:
> On Tue, Jun 30, 2015 at 11:22:37AM +0530, Tejaswini Poluri wrote:
> > Thanks Ben. So should I push the code to the upstream and get an
> approval?
> > Regards,
>
> Yes. Thanks!
>
> -Ben
>
> > Tejaswini
> > On Tue, Jun 30, 2015 at 12:50 AM, Benjamin Marzinski
> > <[1]bmarzins@redhat.com> wrote:
> >
> > On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri wrote:
> > > Yes I agree that having the same code in both cli_add_map() and
> > ev_add_map
> > > is not necessary. Hence I would suggest removing get_refwwid()
> code
> > from
> > > ev_add_map as it is not being used by anyone.
> > >
> > > ev_add_map(param, NULL, vecs) would create the multipath
> device by
> > using
> > > the get_refwwid() code and but all the functions above it like
> > > (dm_get_minor, dm_get_major and dm_mapname) would fail and it
> > wouldn't
> > > enter any of the other code in ev_add_map like
> > > 1.dm_map_present,
> > > 2.add_map_without_path
> > > 3. sync_map_state
> > > which are responsible for registering the map and displaying
> it.
> > >
> > > So, I think moving the below code from ev_add_map to
> cli_add_map
> > should be
> > > a good idea right.
> > >
> > > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > > >
> > > > if (refwwid) {
> > > > r = coalesce_paths(vecs, NULL, refwwid,0);
> > > > dm_lib_release();
> > > > }
> > > What do u think?
> >
> > I agree. We aren't using the code in ev_add_map, so it's presence
> there
> > is simply confusing.
> >
> > -Ben
> > >
> > > Regards,
> > > Tejaswini
> > > On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> > > <[1][2]bmarzins@redhat.com> wrote:
> > >
> > > On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri
> wrote:
> > > > Hi Ben,
> > > >
> > > > This is regarding the add map issue I have been
> discussing.
> > Posting
> > > the
> > > > issue again to remind.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only using
> > #multipath
> > > > command and not using multipathd tools.
> > > >
> > > > I have fixed the problem with two approaches. I would
> like
> > you to
> > > review
> > > > the same.
> > > > Patch1 : By making 'remove map dmpath0' to remove only
> the
> > map and
> > > not the
> > > > device. I have added extra functions discard_map and
> > dm_remove_map
> > > so as
> > > > to not interfere with the existing code.
> > > >
> > > > Patch 2: The approach you have suggested.By getting wwid
> > from the
> > > mapname
> > > > and doing coalesce_paths. I have just moved the
> following
> > code in
> > > > ev_add_map to cli_add_map.
> > >
> > > This is the general idea we'd like to go with. However,
> looking
> > at the
> > > latest upstream code, I don't think you should pull code in
> from
> > > ev_add_map() to cli_add_map() like your patch does.
> cli_add_map()
> > > already calls ev_add_map(), and ev_add_map() is certainly
> able to
> > add
> > > the map if it doesn't already exist.
> > >
> > > You would just need to call it with
> > >
> > > ev_add_map(param, NULL, vecs);
> > >
> > > and ev_add_map() will happily create you a new multipath
> device.
> > All
> > > you need to do is make sure that all the functions that
> > ev_add_map()
> > > calls with alias can accept a NULL value there.
> > >
> > > This might not be the best way to go about this, however. It
> > turns out
> > > that right now, even though ev_add_map() technically has the
> > ability to
> > > create new maps, nothing currently uses it, and it really
> doesn't
> > make
> > > sense for it to be there. Instead of just copying that code,
> you
> > could
> > > pull the map creation code out of ev_add_map() and add it to
> > > cli_add_map(), for those situations where the requested
> device
> > doesn't
> > > already exist.
> > >
> > > But having the code in both cli_add_map() and ev_add_map()
> when
> > one
> > > already calls the other doesn't seem necessary.
> > >
> > > -Ben
> > >
> > > >
> > > > r = get_refwwid(dev, DEV_DEVMAP,
> vecs->pathvec,&refwwid);
> > > >
> > > > if (refwwid) {
> > > > r = coalesce_paths(vecs, NULL,
> refwwid,0);
> > > > dm_lib_release();
> > > > }
> > > >
> > > > changed dev to param.
> > > >
> > > > I have tested the same in all 3 versions -0.4.8, 0.4.9
> and
> > 0.5.0.
> > > It would
> > > > be great if you can review the same so that it doesn't
> cause
> > any
> > > extra
> > > > side effects.
> > > > I guess Patch2 is the way u have suggested me in the
> > previous mail.
> > > Please
> > > > review it and share your views.
> > > > Regards,
> > > > Tejaswini
> > > > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > > > <[1][2][3]bmarzins@redhat.com> wrote:
> > > >
> > > > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini
> Poluri
> > wrote:
> > > > >
> > > > > > We are testing multipathd tools with all the
> > possible
> > > options
> > > > and the
> > > > > > following fails.
> > > > > >
> > > > > > Case 1 : remove and add map.
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > name sysfs uuid
> > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > root@x86-generic-64:~# multipathd
> -k'remove map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > root@x86-generic-64:~# multipathd -k'add
> map
> > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > root@x86-generic-64:~#
> > > > > > Once a map is removed, we are able to add it
> > only using
> > > > #multipath
> > > > > > command and not using multipathd tools.
> > > > >
> > > > > It is working the way it was designed, but
> possibly
> > it would
> > > make
> > > > sense
> > > > > to change the design.
> > > > >
> > > > > You have mentioned that it would make sense to
> change
> > the
> > > design to
> > > > add
> > > > > map. Are there plans to change the design ?
> > > > > I am trying to understand the code flow to
> change the
> > > design. Can
> > > > you
> > > > > guide me if we should stop removing the device
> from
> > in the
> > > remove
> > > > map code
> > > > > flow or start adding the device and the map in
> the
> > add map
> > > code
> > > > flow.
> > > > >
> > > > > have tried to understand the remove map code
> flow of
> > > multipathd in
> > > > 0.4.8
> > > > > code.
> > > >
> > > > I think that we want multipath to actually remove the
> map
> > > (instead of
> > > > just not monitoring it) when you call "remove map
> <map>".
> > We just
> > > want
> > > > "add map <map>" to try to create the map if it doesn't
> > exist. To
> > > do
> > > > that, you would need to first firgure out what WWID is
> > associated
> > > with
> > > > <map>. Presumably, <map> could either be an alias,
> wwid,
> > or even
> > > the
> > > > name of a path in the map. Once you found the map, you
> > would have
> > > to
> > > > call the code to create the map.
> > > >
> > > > Also, to answer your IRC question, no the 0.4.8 code
> is
> > not still
> > > being
> > > > developed upstream. All upstream patches only go
> against
> > the
> > > current
> > > > head. There are no other upstream branches.
> > > >
> > > > -Ben
> > > > >
> > > > > ev_remove_map (char * devname, struct vectors *
> vecs)
> > > > >
> > > > > flush_map(mpp, vecs);
> > > > >
> > > > > dm_flush_map(mpp->alias,
> > > DEFAULT_TARGET);
> > > > >
> > > > > if
> > > (!dm_map_present(mapname))
> > > > >
> > > > > return 0;
> > > > >
> > > > > if (dm_type(mapname, type) <= 0)
> > > > >
> > > > > return 1;
> > > > >
> > > > > if (dm_remove_partmaps(mapname))
> > > > >
> > > > > return 1;
> > > > >
> > > > > if (dm_get_opencount(mapname)) {
> > > > >
> > > > > condlog(2, "%s: map in use",
> mapname);
> > > > >
> > > > > return 1;
> > > > >
> > > > > }
> > > > >
> > > > > r = dm_simplecmd(DM_DEVICE_REMOVE,
> mapname);
> > > > >
> > > > > if (r) {
> > > > >
> > > > > condlog(4, "multipath map %s
> removed",
> > > mapname);
> > > > >
> > > > >
> return
> > 0;
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> orphan_paths(vecs->pathvec,
> > mpp);
> > > > >
> > > > > remove_map(mpp, vecs,
> > > stop_waiter_thread,
> > > > 1);
> > > > >
> > > > > Is removing this below line, the right step to
> stop
> > removing
> > > the
> > > > device ?
> > > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tejaswini
> > > > >
> > > > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri
> > > > > <[1][2][3][4]tejaswinipoluri3@gmail.com> wrote:
> > > > >
> > > > > Thanks a lot Ben for the quick and detailed
> reply.
> > I have
> > > been
> > > > > struggling to understand and conclude the
> issues
> > with
> > > multipath
> > > > as I am
> > > > > the only one working from my team. Your inputs
> help
> > me a
> > > lot.
> > > > Thanks
> > > > > again.
> > > > > Regards,
> > > > > Tejaswini
> > > > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin
> Marzinski
> > > > > <[2][3][4][5]bmarzins@redhat.com> wrote:
> > > > >
> > > > > On Fri, Jun 05, 2015 at 02:31:20PM +0530,
> > Tejaswini
> > > Poluri
> > > > wrote:
> > > > > > Hii Ben,
> > > > > >
> > > > > > We are testing multipathd tools with
> all the
> > > possible
> > > > options and
> > > > > the
> > > > > > following fails.
> > > > > >
> > > > > > Case 1 : remove and add map.
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > name sysfs uuid
> > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > root@x86-generic-64:~# multipathd
> -k'remove
> > map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > root@x86-generic-64:~# multipathd
> -k'add map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > root@x86-generic-64:~#
> > > > > > Once a map is removed, we are able to
> add it
> > only
> > > using
> > > > > #multipath
> > > > > > command and not using multipathd tools.
> > > > >
> > > > > It is working the way it was designed, but
> > possibly it
> > > would
> > > > make
> > > > > sense
> > > > > to change the design. The "remove map"
> command,
> > not
> > > only stops
> > > > > multipathd from monitoring the multipath
> device,
> > but it
> > > removes
> > > > it
> > > > > from
> > > > > the system as well. The "add map" command
> makes
> > > multipath
> > > > monitor an
> > > > > already existing multipath device that in
> wasn't
> > > previously
> > > > > monitoring.
> > > > > These commands do this for historical
> reasons.
> > > multipathd
> > > > wasn't
> > > > > originally in charge of creating multipath
> > devices,
> > > multipath
> > > > was.
> > > > > Once
> > > > > it had created the device, it ran
> > > > >
> > > > > multipathd -k"add map <MAP>"
> > > > >
> > > > > to make multipathd start monitoring it.
> However
> > things
> > > haven't
> > > > worked
> > > > > this way since RHEL4, so possibly "add map"
> > should
> > > actually
> > > > create the
> > > > > device if it doesn't currently exist.
> > > > > > Case 2 : Active paths test case
> > > > > > # while true ; do sleep 3 ; multipathd
> > -k'remove
> > > path sdb'
> > > > ;
> > > > > multipathd
> > > > > > -k'add path sdb' ; multipathd -k'show
> maps
> > status'
> > > ; done
> > > > > > ok
> > > > > > ok
> > > > > > name failback queueing paths dm-st
> > > > > > dmpath0 - - 1 active // It should be 2.
> > > > >
> > > > > This is simply a timing issue. What you are
> > seeing it
> > > the
> > > > number of
> > > > > active paths. These are paths that the
> kernel
> > can use.
> > > The
> > > > "add path"
> > > > > command doesn't update the kernel state.
> This
> > happens
> > > later in
> > > > > response
> > > > > to the kernel reloading the device table.
> So, in
> > a
> > > second or
> > > > two, this
> > > > > will say 2, as expected.
> > > > >
> > > > > > We would like to know if the test cases
> are
> > valid
> > > and if
> > > > these
> > > > > are bugs or
> > > > > > any design issues.
> > > > > >
> > > > > > Case 3 : Fail path and reinstate path
> > > > > > root@x86-generic-64:~# multipathd
> -k"fail
> > path
> > > sdc";
> > > > multipathd
> > > > > > -k'reinstate path sdc'; multipathd
> -k"show
> > paths";
> > > > > > > [ 3962.708523] device-mapper:
> > multipath:
> > > Failing path
> > > > 8:32.
> > > > > > > ok
> > > > > > > ok
> > > > > > > hcil dev dev_t pri dm_st
> chk_st
> > > next_check
> > > > > > > 4:0:0:1 sdc 8:32 1
> [active][faulty]
> > > ..........
> > > > 1/20
> > > > > <==CHECK
> > > > > > > 5:0:0:1 sdd 8:48 1
> [active][ready]
> > > XX........
> > > > 4/20
> > > > > > sdc path becomes [active][ready] only
> after
> > the
> > > polling
> > > > interval
> > > > > but not
> > > > > > immediately after the reinstate path
> > command.
> > > > > > You have answered that this is a design
> > issue. But
> > > we have
> > > > heard
> > > > > from our
> > > > > > test team that the same test case works
> in
> > RHEL6.
> > > Did you
> > > > observe
> > > > > it?
> > > > > > I am also finding that the test cases
> fail
> > because
> > > we are
> > > > trying
> > > > > to do
> > > > > > multiple commands at one shot. Please
> share
> > your
> > > thoughts
> > > > so
> > > > > that it
> > > > > > could help me in debugging the issues
> > further.
> > > > > >
> > > > >
> > > > > It's totally possible that the checker state
> is
> > > immediately
> > > > updated in
> > > > > RHEL6. Like I said before, what it currently
> > does,
> > > although
> > > > correct,
> > > > > is confusing, and perhaps we need a different
> > checker
> > > state for
> > > > paths
> > > > > where the "fail path" command has been used.
> > > > >
> > > > > -Ben
> > > > > > Regards,
> > > > > > Tejaswini
> > > > > > On Tue, May 19, 2015 at 5:37 PM,
> Tejaswini
> > Poluri
> > > > > > <[1][3][4][5][6]
> tejaswinipoluri3@gmail.com>
> > wrote:
> > > > > >
> > > > > > Thanks a lot Ben. I will look into it
> > more.
> > > > > > On Mon, May 18, 2015 at 9:57 PM,
> Benjamin
> > > Marzinski
> > > > > > <[2][4][5][6][7]bmarzins@redhat.com>
> > wrote:
> > > > > >
> > > > > > On Mon, May 18, 2015 at 02:09:27PM
> > +0530,
> > > Tejaswini
> > > > Poluri
> > > > > wrote:
> > > > > > > Hii,
> > > > > > > We are trying to test multipath
> > setup in
> > > our
> > > > target and
> > > > > tried the
> > > > > > various
> > > > > > > commands of multipathd demaon
> and
> > we find
> > > the
> > > > following
> > > > > error:
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k"fail
> > > path
> > > > sdc";
> > > > > multipathd
> > > > > > > -k'reinstate path
> > > > > > > sdc'; multipathd -k"show
> paths";
> > > > > > > [ 3962.708523] device-mapper:
> > multipath:
> > > Failing
> > > > > path 8:32.
> > > > > > > ok
> > > > > > > ok
> > > > > > > hcil dev dev_t pri dm_st
> > chk_st
> > > next_check
> > > > > > > 4:0:0:1 sdc 8:32 1
> > [active][faulty]
> > > ..........
> > > > 1/20
> > > > > <<<===
> > > > > > CHECK
> > > > > > > 5:0:0:1 sdd 8:48 1
> > [active][ready]
> > > XX........
> > > > 4/20
> > > > > > > sdc path becomes
> [active][ready]
> > only
> > > after the
> > > > polling
> > > > > interval
> > > > > > but not
> > > > > > > immediately after the reinstate
> > path
> > > command.
> > > > > > > I am observing this in latest
> > multipath
> > > tools in
> > > > ubuntu
> > > > > machine
> > > > > > as well.
> > > > > > > Please let me know if its a
> known
> > issue or
> > > if I
> > > > am doing
> > > > > > something wrong.
> > > > > > > Regards.
> > > > > > > Tejaswini
> > > > > >
> > > > > > the reinstate command is supposed to
> > reinstate
> > > the
> > > > device
> > > > > with the
> > > > > > kernel, and it does that. The
> checker
> > state
> > > doesn't
> > > > change
> > > > > until the
> > > > > > next time that the path is
> checked. I
> > agree
> > > that it's
> > > > odd
> > > > > that the
> > > > > > check state switches to faulty as
> soon
> > as you
> > > fail the
> > > > path,
> > > > > but it
> > > > > > doesn't switch back until the next
> check
> > after
> > > you
> > > > reinistate
> > > > > it.
> > > > > >
> > > > > > The issue is that multipathd needs
> to
> > override
> > > the
> > > > checker
> > > > > output,
> > > > > > so that a failed path won't be
> > immeditately
> > > > reinstated. Once
> > > > > the
> > > > > > path comes back, multipathd wants to
> > record the
> > > switch
> > > > in the
> > > > > checker
> > > > > > thread, so that it can refresh path
> > information
> > > what
> > > > wasn't
> > > > > > automatically done when the path was
> > > reinstated.
> > > > However, it
> > > > > may make
> > > > > > more sense to have a different
> checker
> > state
> > > for when
> > > > the
> > > > > device is
> > > > > > in the failed state, so that it's
> > obvious that
> > > the
> > > > checker
> > > > > state is
> > > > > > being overruled.
> > > > > >
> > > > > > -Ben
> > > > > >
> > > > > > > --
> > > > > > > dm-devel mailing list
> > > > > > > [3][5][6][7][8]
> dm-devel@redhat.com
> > > > > > >
> > > >
> > [4][6][7][8][9]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > >
> > > > > > --
> > > > > > dm-devel mailing list
> > > > > > [5][7][8][9][10]dm-devel@redhat.com
> > > > > >
> > > >
> > [6][8][9][10][11]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1.
> > mailto:[9][10][11][12]tejaswinipoluri3@gmail.com
> > > > > > 2.
> > mailto:[10][11][12][13]bmarzins@redhat.com
> > > > > > 3.
> > mailto:[11][12][13][14]dm-devel@redhat.com
> > > > > > 4.
> > > >
> > [12][13][14][15]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > 5.
> > mailto:[13][14][15][16]dm-devel@redhat.com
> > > > > > 6.
> > > >
> > [14][15][16][17]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1. mailto:[16][17][18]tejaswinipoluri3@gmail.com
> > > > > 2. mailto:[17][18][19]bmarzins@redhat.com
> > > > > 3. mailto:[18][19][20]tejaswinipoluri3@gmail.com
> > > > > 4. mailto:[19][20][21]bmarzins@redhat.com
> > > > > 5. mailto:[20][21][22]dm-devel@redhat.com
> > > > > 6.
> > [21][22][23]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 7. mailto:[22][23][24]dm-devel@redhat.com
> > > > > 8.
> > [23][24][25]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 9. mailto:[24][25][26]tejaswinipoluri3@gmail.com
> > > > > 10. mailto:[25][26][27]bmarzins@redhat.com
> > > > > 11. mailto:[26][27][28]dm-devel@redhat.com
> > > > > 12.
> > [27][28][29]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 13. mailto:[28][29][30]dm-devel@redhat.com
> > > > > 14.
> > [29][30][31]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[31][32]bmarzins@redhat.com
> > > > 2. mailto:[32][33]tejaswinipoluri3@gmail.com
> > > > 3. mailto:[33][34]bmarzins@redhat.com
> > > > 4. mailto:[34][35]tejaswinipoluri3@gmail.com
> > > > 5. mailto:[35][36]bmarzins@redhat.com
> > > > 6. mailto:[36][37]dm-devel@redhat.com
> > > > 7. [37][38]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 8. mailto:[38][39]dm-devel@redhat.com
> > > > 9. [39][40]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 10. mailto:[40][41]tejaswinipoluri3@gmail.com
> > > > 11. mailto:[41][42]bmarzins@redhat.com
> > > > 12. mailto:[42][43]dm-devel@redhat.com
> > > > 13. [43][44]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 14. mailto:[44][45]dm-devel@redhat.com
> > > > 15. [45][46]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 16. mailto:[46][47]tejaswinipoluri3@gmail.com
> > > > 17. mailto:[47][48]bmarzins@redhat.com
> > > > 18. mailto:[48][49]tejaswinipoluri3@gmail.com
> > > > 19. mailto:[49][50]bmarzins@redhat.com
> > > > 20. mailto:[50][51]dm-devel@redhat.com
> > > > 21. [51][52]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 22. mailto:[52][53]dm-devel@redhat.com
> > > > 23. [53][54]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 24. mailto:[54][55]tejaswinipoluri3@gmail.com
> > > > 25. mailto:[55][56]bmarzins@redhat.com
> > > > 26. mailto:[56][57]dm-devel@redhat.com
> > > > 27. [57][58]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 28. mailto:[58][59]dm-devel@redhat.com
> > > > 29. [59][60]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[61]bmarzins@redhat.com
> > > 2. mailto:[62]bmarzins@redhat.com
> > > 3. mailto:[63]tejaswinipoluri3@gmail.com
> > > 4. mailto:[64]bmarzins@redhat.com
> > > 5. mailto:[65]tejaswinipoluri3@gmail.com
> > > 6. mailto:[66]bmarzins@redhat.com
> > > 7. mailto:[67]dm-devel@redhat.com
> > > 8. [68]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 9. mailto:[69]dm-devel@redhat.com
> > > 10. [70]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 11. mailto:[71]tejaswinipoluri3@gmail.com
> > > 12. mailto:[72]bmarzins@redhat.com
> > > 13. mailto:[73]dm-devel@redhat.com
> > > 14. [74]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 15. mailto:[75]dm-devel@redhat.com
> > > 16. [76]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 17. mailto:[77]tejaswinipoluri3@gmail.com
> > > 18. mailto:[78]bmarzins@redhat.com
> > > 19. mailto:[79]tejaswinipoluri3@gmail.com
> > > 20. mailto:[80]bmarzins@redhat.com
> > > 21. mailto:[81]dm-devel@redhat.com
> > > 22. [82]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 23. mailto:[83]dm-devel@redhat.com
> > > 24. [84]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 25. mailto:[85]tejaswinipoluri3@gmail.com
> > > 26. mailto:[86]bmarzins@redhat.com
> > > 27. mailto:[87]dm-devel@redhat.com
> > > 28. [88]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 29. mailto:[89]dm-devel@redhat.com
> > > 30. [90]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 31. mailto:[91]bmarzins@redhat.com
> > > 32. mailto:[92]tejaswinipoluri3@gmail.com
> > > 33. mailto:[93]bmarzins@redhat.com
> > > 34. mailto:[94]tejaswinipoluri3@gmail.com
> > > 35. mailto:[95]bmarzins@redhat.com
> > > 36. mailto:[96]dm-devel@redhat.com
> > > 37. [97]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 38. mailto:[98]dm-devel@redhat.com
> > > 39. [99]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 40. mailto:[100]tejaswinipoluri3@gmail.com
> > > 41. mailto:[101]bmarzins@redhat.com
> > > 42. mailto:[102]dm-devel@redhat.com
> > > 43. [103]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 44. mailto:[104]dm-devel@redhat.com
> > > 45. [105]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 46. mailto:[106]tejaswinipoluri3@gmail.com
> > > 47. mailto:[107]bmarzins@redhat.com
> > > 48. mailto:[108]tejaswinipoluri3@gmail.com
> > > 49. mailto:[109]bmarzins@redhat.com
> > > 50. mailto:[110]dm-devel@redhat.com
> > > 51. [111]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 52. mailto:[112]dm-devel@redhat.com
> > > 53. [113]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 54. mailto:[114]tejaswinipoluri3@gmail.com
> > > 55. mailto:[115]bmarzins@redhat.com
> > > 56. mailto:[116]dm-devel@redhat.com
> > > 57. [117]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 58. mailto:[118]dm-devel@redhat.com
> > > 59. [119]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:bmarzins@redhat.com
> > 2. mailto:bmarzins@redhat.com
> > 3. mailto:bmarzins@redhat.com
> > 4. mailto:tejaswinipoluri3@gmail.com
> > 5. mailto:bmarzins@redhat.com
> > 6. mailto:tejaswinipoluri3@gmail.com
> > 7. mailto:bmarzins@redhat.com
> > 8. mailto:dm-devel@redhat.com
> > 9. https://www.redhat.com/mailman/listinfo/dm-devel
> > 10. mailto:dm-devel@redhat.com
> > 11. https://www.redhat.com/mailman/listinfo/dm-devel
> > 12. mailto:tejaswinipoluri3@gmail.com
> > 13. mailto:bmarzins@redhat.com
> > 14. mailto:dm-devel@redhat.com
> > 15. https://www.redhat.com/mailman/listinfo/dm-devel
> > 16. mailto:dm-devel@redhat.com
> > 17. https://www.redhat.com/mailman/listinfo/dm-devel
> > 18. mailto:tejaswinipoluri3@gmail.com
> > 19. mailto:bmarzins@redhat.com
> > 20. mailto:tejaswinipoluri3@gmail.com
> > 21. mailto:bmarzins@redhat.com
> > 22. mailto:dm-devel@redhat.com
> > 23. https://www.redhat.com/mailman/listinfo/dm-devel
> > 24. mailto:dm-devel@redhat.com
> > 25. https://www.redhat.com/mailman/listinfo/dm-devel
> > 26. mailto:tejaswinipoluri3@gmail.com
> > 27. mailto:bmarzins@redhat.com
> > 28. mailto:dm-devel@redhat.com
> > 29. https://www.redhat.com/mailman/listinfo/dm-devel
> > 30. mailto:dm-devel@redhat.com
> > 31. https://www.redhat.com/mailman/listinfo/dm-devel
> > 32. mailto:bmarzins@redhat.com
> > 33. mailto:tejaswinipoluri3@gmail.com
> > 34. mailto:bmarzins@redhat.com
> > 35. mailto:tejaswinipoluri3@gmail.com
> > 36. mailto:bmarzins@redhat.com
> > 37. mailto:dm-devel@redhat.com
> > 38. https://www.redhat.com/mailman/listinfo/dm-devel
> > 39. mailto:dm-devel@redhat.com
> > 40. https://www.redhat.com/mailman/listinfo/dm-devel
> > 41. mailto:tejaswinipoluri3@gmail.com
> > 42. mailto:bmarzins@redhat.com
> > 43. mailto:dm-devel@redhat.com
> > 44. https://www.redhat.com/mailman/listinfo/dm-devel
> > 45. mailto:dm-devel@redhat.com
> > 46. https://www.redhat.com/mailman/listinfo/dm-devel
> > 47. mailto:tejaswinipoluri3@gmail.com
> > 48. mailto:bmarzins@redhat.com
> > 49. mailto:tejaswinipoluri3@gmail.com
> > 50. mailto:bmarzins@redhat.com
> > 51. mailto:dm-devel@redhat.com
> > 52. https://www.redhat.com/mailman/listinfo/dm-devel
> > 53. mailto:dm-devel@redhat.com
> > 54. https://www.redhat.com/mailman/listinfo/dm-devel
> > 55. mailto:tejaswinipoluri3@gmail.com
> > 56. mailto:bmarzins@redhat.com
> > 57. mailto:dm-devel@redhat.com
> > 58. https://www.redhat.com/mailman/listinfo/dm-devel
> > 59. mailto:dm-devel@redhat.com
> > 60. https://www.redhat.com/mailman/listinfo/dm-devel
> > 61. mailto:bmarzins@redhat.com
> > 62. mailto:bmarzins@redhat.com
> > 63. mailto:tejaswinipoluri3@gmail.com
> > 64. mailto:bmarzins@redhat.com
> > 65. mailto:tejaswinipoluri3@gmail.com
> > 66. mailto:bmarzins@redhat.com
> > 67. mailto:dm-devel@redhat.com
> > 68. https://www.redhat.com/mailman/listinfo/dm-devel
> > 69. mailto:dm-devel@redhat.com
> > 70. https://www.redhat.com/mailman/listinfo/dm-devel
> > 71. mailto:tejaswinipoluri3@gmail.com
> > 72. mailto:bmarzins@redhat.com
> > 73. mailto:dm-devel@redhat.com
> > 74. https://www.redhat.com/mailman/listinfo/dm-devel
> > 75. mailto:dm-devel@redhat.com
> > 76. https://www.redhat.com/mailman/listinfo/dm-devel
> > 77. mailto:tejaswinipoluri3@gmail.com
> > 78. mailto:bmarzins@redhat.com
> > 79. mailto:tejaswinipoluri3@gmail.com
> > 80. mailto:bmarzins@redhat.com
> > 81. mailto:dm-devel@redhat.com
> > 82. https://www.redhat.com/mailman/listinfo/dm-devel
> > 83. mailto:dm-devel@redhat.com
> > 84. https://www.redhat.com/mailman/listinfo/dm-devel
> > 85. mailto:tejaswinipoluri3@gmail.com
> > 86. mailto:bmarzins@redhat.com
> > 87. mailto:dm-devel@redhat.com
> > 88. https://www.redhat.com/mailman/listinfo/dm-devel
> > 89. mailto:dm-devel@redhat.com
> > 90. https://www.redhat.com/mailman/listinfo/dm-devel
> > 91. mailto:bmarzins@redhat.com
> > 92. mailto:tejaswinipoluri3@gmail.com
> > 93. mailto:bmarzins@redhat.com
> > 94. mailto:tejaswinipoluri3@gmail.com
> > 95. mailto:bmarzins@redhat.com
> > 96. mailto:dm-devel@redhat.com
> > 97. https://www.redhat.com/mailman/listinfo/dm-devel
> > 98. mailto:dm-devel@redhat.com
> > 99. https://www.redhat.com/mailman/listinfo/dm-devel
> > 100. mailto:tejaswinipoluri3@gmail.com
> > 101. mailto:bmarzins@redhat.com
> > 102. mailto:dm-devel@redhat.com
> > 103. https://www.redhat.com/mailman/listinfo/dm-devel
> > 104. mailto:dm-devel@redhat.com
> > 105. https://www.redhat.com/mailman/listinfo/dm-devel
> > 106. mailto:tejaswinipoluri3@gmail.com
> > 107. mailto:bmarzins@redhat.com
> > 108. mailto:tejaswinipoluri3@gmail.com
> > 109. mailto:bmarzins@redhat.com
> > 110. mailto:dm-devel@redhat.com
> > 111. https://www.redhat.com/mailman/listinfo/dm-devel
> > 112. mailto:dm-devel@redhat.com
> > 113. https://www.redhat.com/mailman/listinfo/dm-devel
> > 114. mailto:tejaswinipoluri3@gmail.com
> > 115. mailto:bmarzins@redhat.com
> > 116. mailto:dm-devel@redhat.com
> > 117. https://www.redhat.com/mailman/listinfo/dm-devel
> > 118. mailto:dm-devel@redhat.com
> > 119. https://www.redhat.com/mailman/listinfo/dm-devel
>
[-- Attachment #1.2: Type: text/html, Size: 72941 bytes --]
[-- Attachment #2: add_map.patch --]
[-- Type: text/x-patch, Size: 1662 bytes --]
commit 79ab9090d3fbcdb5844478419135d1390cf548c2
Author: Tejaswini <tejaswinipoluri3@gmail.com>
Date: Wed Jul 8 15:08:56 2015 +0530
multipathd: Fixing add map functionality
Add map feature of multipathd tools fails as the device
is also been completely removed along with removing the map
in the remove map code. So when add map is called we are
creating the device again in kernel and doing add map
using the coloasce_paths code.
Signed-off-by: Tejaswini Poluri <tpoluri@mvista.com>
diff --git a/multipathd/cli_handlers.c b/multipathd/cli_handlers.c
index dc96c45..c54c767 100644
--- a/multipathd/cli_handlers.c
+++ b/multipathd/cli_handlers.c
@@ -537,7 +537,7 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
char dev_path[PATH_SIZE];
char *alias;
int rc;
-
+ char *refwwid;
param = convert_dev(param, 0);
condlog(2, "%s: add map (operator)", param);
@@ -547,6 +547,14 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
condlog(2, "%s: map blacklisted", param);
return 0;
}
+ rc = get_refwwid(param, DEV_DEVMAP, vecs->pathvec, &refwwid);
+
+ if (refwwid) {
+ condlog(2, "%s: add map (operator)", refwwid);
+ if(coalesce_paths(vecs, NULL, refwwid, 0))
+ condlog(2, "%s: coalesce-paths failed", param);
+ dm_lib_release();
+ }
minor = dm_get_minor(param);
if (minor < 0) {
condlog(2, "%s: not a device mapper table", param);
@@ -566,6 +574,7 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
}
rc = ev_add_map(dev_path, alias, vecs);
FREE(alias);
+ FREE(refwwid);
return rc;
}
[-- Attachment #3: disable_code.patch --]
[-- Type: text/x-patch, Size: 983 bytes --]
commit 910b4a82ec483b48eaf8b24eb3d7829273c690ed
Author: Tejaswini <tejaswinipoluri3@gmail.com>
Date: Wed Jul 8 17:18:03 2015 +0530
multipathd: Disabled code that is not being used.
This part of the code is moved to cli_add_map and
disabled here as it is not used by any function call
here.
Signed-off-by: Tejaswini <tejaswinipoluri3@gmail.com>
diff --git a/multipathd/main.c b/multipathd/main.c
index f876258..060237c 100644
--- a/multipathd/main.c
+++ b/multipathd/main.c
@@ -329,6 +329,8 @@ ev_add_map (char * dev, char * alias, struct vectors * vecs)
return 1;
}
}
+#if 0 /*Disabled as the code is not being used by anyone.
+ TODO:confirm that no feature requires this code*/
r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec, &refwwid);
if (refwwid) {
@@ -344,6 +346,7 @@ ev_add_map (char * dev, char * alias, struct vectors * vecs)
condlog(0, "%s: uev_add_map %s failed", alias, dev);
FREE(refwwid);
+#endif
return r;
}
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-07-08 12:01 ` Tejaswini Poluri
@ 2015-07-10 16:06 ` Benjamin Marzinski
2015-07-16 10:37 ` Tejaswini Poluri
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Marzinski @ 2015-07-10 16:06 UTC (permalink / raw)
To: Tejaswini Poluri; +Cc: device-mapper development
On Wed, Jul 08, 2015 at 05:31:26PM +0530, Tejaswini Poluri wrote:
> Thanks a lot.
> Can you guide me how to push upstream for the approval. Which branch
> should I push to? Any list of testcases I should perform before I could
> push?
All you do is post it to dm-devel. I think it's easier for Christophe
to pull the patches in, if you post them directly in the email. "git
format-patch" and "git send-email" make this a lot faster.
Please do whatever testing you feel is appropriate before posting.
About the patches specifically: In cli_add_map(), wouldn't it make more
sense to only do the coalesce_paths() if dm_mapname() fails. If it
succeeds you clearly already have an existing map, so you don't need to
create one.
-Ben
> I have created the following two patches. PFA
> Regards,
> Tejaswini
> On Mon, Jul 6, 2015 at 11:15 PM, Benjamin Marzinski
> <[1]bmarzins@redhat.com> wrote:
>
> On Tue, Jun 30, 2015 at 11:22:37AM +0530, Tejaswini Poluri wrote:
> > Thanks Ben. So should I push the code to the upstream and get an
> approval?
> > Regards,
>
> Yes. Thanks!
>
> -Ben
> > Tejaswini
> > On Tue, Jun 30, 2015 at 12:50 AM, Benjamin Marzinski
> > <[1][2]bmarzins@redhat.com> wrote:
> >
> > On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri wrote:
> > > Yes I agree that having the same code in both cli_add_map()
> and
> > ev_add_map
> > > is not necessary. Hence I would suggest removing
> get_refwwid() code
> > from
> > > ev_add_map as it is not being used by anyone.
> > >
> > > ev_add_map(param, NULL, vecs) would create the multipath
> device by
> > using
> > > the get_refwwid() code and but all the functions above it
> like
> > > (dm_get_minor, dm_get_major and dm_mapname) would fail and
> it
> > wouldn't
> > > enter any of the other code in ev_add_map like
> > > 1.dm_map_present,
> > > 2.add_map_without_path
> > > 3. sync_map_state
> > > which are responsible for registering the map and displaying
> it.
> > >
> > > So, I think moving the below code from ev_add_map to
> cli_add_map
> > should be
> > > a good idea right.
> > >
> > > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);
> > > >
> > > > if (refwwid) {
> > > > r = coalesce_paths(vecs, NULL,
> refwwid,0);
> > > > dm_lib_release();
> > > > }
> > > What do u think?
> >
> > I agree. We aren't using the code in ev_add_map, so it's presence
> there
> > is simply confusing.
> >
> > -Ben
> > >
> > > Regards,
> > > Tejaswini
> > > On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> > > <[1][2][3]bmarzins@redhat.com> wrote:
> > >
> > > On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri
> wrote:
> > > > Hi Ben,
> > > >
> > > > This is regarding the add map issue I have been
> discussing.
> > Posting
> > > the
> > > > issue again to remind.
> > > >
> > > > Case 1 : remove and add map.
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > name sysfs uuid
> > > > dmpath0 dm-0 1IET_00010001
> > > > root@x86-generic-64:~# multipathd -k'remove map
> dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~# multipathd -k'add map dmpath0'
> > > > ok
> > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > root@x86-generic-64:~#
> > > > Once a map is removed, we are able to add it only
> using
> > #multipath
> > > > command and not using multipathd tools.
> > > >
> > > > I have fixed the problem with two approaches. I would
> like
> > you to
> > > review
> > > > the same.
> > > > Patch1 : By making 'remove map dmpath0' to remove
> only the
> > map and
> > > not the
> > > > device. I have added extra functions discard_map and
> > dm_remove_map
> > > so as
> > > > to not interfere with the existing code.
> > > >
> > > > Patch 2: The approach you have suggested.By getting
> wwid
> > from the
> > > mapname
> > > > and doing coalesce_paths. I have just moved the
> following
> > code in
> > > > ev_add_map to cli_add_map.
> > >
> > > This is the general idea we'd like to go with. However,
> looking
> > at the
> > > latest upstream code, I don't think you should pull code
> in from
> > > ev_add_map() to cli_add_map() like your patch does.
> cli_add_map()
> > > already calls ev_add_map(), and ev_add_map() is certainly
> able to
> > add
> > > the map if it doesn't already exist.
> > >
> > > You would just need to call it with
> > >
> > > ev_add_map(param, NULL, vecs);
> > >
> > > and ev_add_map() will happily create you a new multipath
> device.
> > All
> > > you need to do is make sure that all the functions that
> > ev_add_map()
> > > calls with alias can accept a NULL value there.
> > >
> > > This might not be the best way to go about this, however.
> It
> > turns out
> > > that right now, even though ev_add_map() technically has
> the
> > ability to
> > > create new maps, nothing currently uses it, and it really
> doesn't
> > make
> > > sense for it to be there. Instead of just copying that
> code, you
> > could
> > > pull the map creation code out of ev_add_map() and add it
> to
> > > cli_add_map(), for those situations where the requested
> device
> > doesn't
> > > already exist.
> > >
> > > But having the code in both cli_add_map() and ev_add_map()
> when
> > one
> > > already calls the other doesn't seem necessary.
> > >
> > > -Ben
> > >
> > > >
> > > > r = get_refwwid(dev, DEV_DEVMAP,
> vecs->pathvec,&refwwid);
> > > >
> > > > if (refwwid) {
> > > > r = coalesce_paths(vecs, NULL,
> refwwid,0);
> > > > dm_lib_release();
> > > > }
> > > >
> > > > changed dev to param.
> > > >
> > > > I have tested the same in all 3 versions -0.4.8,
> 0.4.9 and
> > 0.5.0.
> > > It would
> > > > be great if you can review the same so that it
> doesn't cause
> > any
> > > extra
> > > > side effects.
> > > > I guess Patch2 is the way u have suggested me in the
> > previous mail.
> > > Please
> > > > review it and share your views.
> > > > Regards,
> > > > Tejaswini
> > > > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski
> > > > <[1][2][3][4]bmarzins@redhat.com> wrote:
> > > >
> > > > On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini
> Poluri
> > wrote:
> > > > >
> > > > > > We are testing multipathd tools with all
> the
> > possible
> > > options
> > > > and the
> > > > > > following fails.
> > > > > >
> > > > > > Case 1 : remove and add map.
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > name sysfs uuid
> > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > root@x86-generic-64:~# multipathd
> -k'remove map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > root@x86-generic-64:~# multipathd -k'add
> map
> > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd -k'show
> maps'
> > > > > > root@x86-generic-64:~#
> > > > > > Once a map is removed, we are able to add
> it
> > only using
> > > > #multipath
> > > > > > command and not using multipathd tools.
> > > > >
> > > > > It is working the way it was designed, but
> possibly
> > it would
> > > make
> > > > sense
> > > > > to change the design.
> > > > >
> > > > > You have mentioned that it would make sense to
> change
> > the
> > > design to
> > > > add
> > > > > map. Are there plans to change the design ?
> > > > > I am trying to understand the code flow to
> change the
> > > design. Can
> > > > you
> > > > > guide me if we should stop removing the device
> from
> > in the
> > > remove
> > > > map code
> > > > > flow or start adding the device and the map in
> the
> > add map
> > > code
> > > > flow.
> > > > >
> > > > > have tried to understand the remove map code
> flow of
> > > multipathd in
> > > > 0.4.8
> > > > > code.
> > > >
> > > > I think that we want multipath to actually remove
> the map
> > > (instead of
> > > > just not monitoring it) when you call "remove map
> <map>".
> > We just
> > > want
> > > > "add map <map>" to try to create the map if it
> doesn't
> > exist. To
> > > do
> > > > that, you would need to first firgure out what WWID
> is
> > associated
> > > with
> > > > <map>. Presumably, <map> could either be an alias,
> wwid,
> > or even
> > > the
> > > > name of a path in the map. Once you found the map,
> you
> > would have
> > > to
> > > > call the code to create the map.
> > > >
> > > > Also, to answer your IRC question, no the 0.4.8
> code is
> > not still
> > > being
> > > > developed upstream. All upstream patches only go
> against
> > the
> > > current
> > > > head. There are no other upstream branches.
> > > >
> > > > -Ben
> > > > >
> > > > > ev_remove_map (char * devname, struct vectors
> * vecs)
> > > > >
> > > > > flush_map(mpp, vecs);
> > > > >
> > > > >
> dm_flush_map(mpp->alias,
> > > DEFAULT_TARGET);
> > > > >
> > > > > if
> > > (!dm_map_present(mapname))
> > > > >
> > > > > return
> 0;
> > > > >
> > > > > if (dm_type(mapname, type) <= 0)
> > > > >
> > > > > return 1;
> > > > >
> > > > > if (dm_remove_partmaps(mapname))
> > > > >
> > > > > return 1;
> > > > >
> > > > > if (dm_get_opencount(mapname)) {
> > > > >
> > > > > condlog(2, "%s: map in use",
> mapname);
> > > > >
> > > > > return 1;
> > > > >
> > > > > }
> > > > >
> > > > > r = dm_simplecmd(DM_DEVICE_REMOVE,
> mapname);
> > > > >
> > > > > if (r) {
> > > > >
> > > > > condlog(4, "multipath map %s
> removed",
> > > mapname);
> > > > >
> > > > >
> return
> > 0;
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> orphan_paths(vecs->pathvec,
> > mpp);
> > > > >
> > > > > remove_map(mpp, vecs,
> > > stop_waiter_thread,
> > > > 1);
> > > > >
> > > > > Is removing this below line, the right step to
> stop
> > removing
> > > the
> > > > device ?
> > > > > r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tejaswini
> > > > >
> > > > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini
> Poluri
> > > > > <[1][2][3][4][5]tejaswinipoluri3@gmail.com>
> wrote:
> > > > >
> > > > > Thanks a lot Ben for the quick and detailed
> reply.
> > I have
> > > been
> > > > > struggling to understand and conclude the
> issues
> > with
> > > multipath
> > > > as I am
> > > > > the only one working from my team. Your
> inputs help
> > me a
> > > lot.
> > > > Thanks
> > > > > again.
> > > > > Regards,
> > > > > Tejaswini
> > > > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin
> Marzinski
> > > > > <[2][3][4][5][6]bmarzins@redhat.com> wrote:
> > > > >
> > > > > On Fri, Jun 05, 2015 at 02:31:20PM +0530,
> > Tejaswini
> > > Poluri
> > > > wrote:
> > > > > > Hii Ben,
> > > > > >
> > > > > > We are testing multipathd tools with
> all the
> > > possible
> > > > options and
> > > > > the
> > > > > > following fails.
> > > > > >
> > > > > > Case 1 : remove and add map.
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > name sysfs uuid
> > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > root@x86-generic-64:~# multipathd
> -k'remove
> > map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > root@x86-generic-64:~# multipathd
> -k'add map
> > > dmpath0'
> > > > > > ok
> > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > root@x86-generic-64:~#
> > > > > > Once a map is removed, we are able to
> add it
> > only
> > > using
> > > > > #multipath
> > > > > > command and not using multipathd
> tools.
> > > > >
> > > > > It is working the way it was designed, but
> > possibly it
> > > would
> > > > make
> > > > > sense
> > > > > to change the design. The "remove map"
> command,
> > not
> > > only stops
> > > > > multipathd from monitoring the multipath
> device,
> > but it
> > > removes
> > > > it
> > > > > from
> > > > > the system as well. The "add map" command
> makes
> > > multipath
> > > > monitor an
> > > > > already existing multipath device that in
> wasn't
> > > previously
> > > > > monitoring.
> > > > > These commands do this for historical
> reasons.
> > > multipathd
> > > > wasn't
> > > > > originally in charge of creating multipath
> > devices,
> > > multipath
> > > > was.
> > > > > Once
> > > > > it had created the device, it ran
> > > > >
> > > > > multipathd -k"add map <MAP>"
> > > > >
> > > > > to make multipathd start monitoring it.
> However
> > things
> > > haven't
> > > > worked
> > > > > this way since RHEL4, so possibly "add
> map"
> > should
> > > actually
> > > > create the
> > > > > device if it doesn't currently exist.
> > > > > > Case 2 : Active paths test case
> > > > > > # while true ; do sleep 3 ;
> multipathd
> > -k'remove
> > > path sdb'
> > > > ;
> > > > > multipathd
> > > > > > -k'add path sdb' ; multipathd -k'show
> maps
> > status'
> > > ; done
> > > > > > ok
> > > > > > ok
> > > > > > name failback queueing paths dm-st
> > > > > > dmpath0 - - 1 active // It should be
> 2.
> > > > >
> > > > > This is simply a timing issue. What you
> are
> > seeing it
> > > the
> > > > number of
> > > > > active paths. These are paths that the
> kernel
> > can use.
> > > The
> > > > "add path"
> > > > > command doesn't update the kernel state.
> This
> > happens
> > > later in
> > > > > response
> > > > > to the kernel reloading the device table.
> So, in
> > a
> > > second or
> > > > two, this
> > > > > will say 2, as expected.
> > > > >
> > > > > > We would like to know if the test
> cases are
> > valid
> > > and if
> > > > these
> > > > > are bugs or
> > > > > > any design issues.
> > > > > >
> > > > > > Case 3 : Fail path and reinstate path
> > > > > > root@x86-generic-64:~# multipathd
> -k"fail
> > path
> > > sdc";
> > > > multipathd
> > > > > > -k'reinstate path sdc'; multipathd
> -k"show
> > paths";
> > > > > > > [ 3962.708523] device-mapper:
> > multipath:
> > > Failing path
> > > > 8:32.
> > > > > > > ok
> > > > > > > ok
> > > > > > > hcil dev dev_t pri dm_st
> chk_st
> > > next_check
> > > > > > > 4:0:0:1 sdc 8:32 1
> [active][faulty]
> > > ..........
> > > > 1/20
> > > > > <==CHECK
> > > > > > > 5:0:0:1 sdd 8:48 1
> [active][ready]
> > > XX........
> > > > 4/20
> > > > > > sdc path becomes [active][ready] only
> after
> > the
> > > polling
> > > > interval
> > > > > but not
> > > > > > immediately after the reinstate path
> > command.
> > > > > > You have answered that this is a
> design
> > issue. But
> > > we have
> > > > heard
> > > > > from our
> > > > > > test team that the same test case
> works in
> > RHEL6.
> > > Did you
> > > > observe
> > > > > it?
> > > > > > I am also finding that the test cases
> fail
> > because
> > > we are
> > > > trying
> > > > > to do
> > > > > > multiple commands at one shot.
> Please share
> > your
> > > thoughts
> > > > so
> > > > > that it
> > > > > > could help me in debugging the issues
> > further.
> > > > > >
> > > > >
> > > > > It's totally possible that the checker
> state is
> > > immediately
> > > > updated in
> > > > > RHEL6. Like I said before, what it
> currently
> > does,
> > > although
> > > > correct,
> > > > > is confusing, and perhaps we need a
> different
> > checker
> > > state for
> > > > paths
> > > > > where the "fail path" command has been
> used.
> > > > >
> > > > > -Ben
> > > > > > Regards,
> > > > > > Tejaswini
> > > > > > On Tue, May 19, 2015 at 5:37 PM,
> Tejaswini
> > Poluri
> > > > > >
> <[1][3][4][5][6][7]tejaswinipoluri3@gmail.com>
> > wrote:
> > > > > >
> > > > > > Thanks a lot Ben. I will look into
> it
> > more.
> > > > > > On Mon, May 18, 2015 at 9:57 PM,
> Benjamin
> > > Marzinski
> > > > > >
> <[2][4][5][6][7][8]bmarzins@redhat.com>
> > wrote:
> > > > > >
> > > > > > On Mon, May 18, 2015 at
> 02:09:27PM
> > +0530,
> > > Tejaswini
> > > > Poluri
> > > > > wrote:
> > > > > > > Hii,
> > > > > > > We are trying to test
> multipath
> > setup in
> > > our
> > > > target and
> > > > > tried the
> > > > > > various
> > > > > > > commands of multipathd
> demaon and
> > we find
> > > the
> > > > following
> > > > > error:
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k"fail
> > > path
> > > > sdc";
> > > > > multipathd
> > > > > > > -k'reinstate path
> > > > > > > sdc'; multipathd -k"show
> paths";
> > > > > > > [ 3962.708523]
> device-mapper:
> > multipath:
> > > Failing
> > > > > path 8:32.
> > > > > > > ok
> > > > > > > ok
> > > > > > > hcil dev dev_t pri dm_st
> > chk_st
> > > next_check
> > > > > > > 4:0:0:1 sdc 8:32 1
> > [active][faulty]
> > > ..........
> > > > 1/20
> > > > > <<<===
> > > > > > CHECK
> > > > > > > 5:0:0:1 sdd 8:48 1
> > [active][ready]
> > > XX........
> > > > 4/20
> > > > > > > sdc path becomes
> [active][ready]
> > only
> > > after the
> > > > polling
> > > > > interval
> > > > > > but not
> > > > > > > immediately after the
> reinstate
> > path
> > > command.
> > > > > > > I am observing this in
> latest
> > multipath
> > > tools in
> > > > ubuntu
> > > > > machine
> > > > > > as well.
> > > > > > > Please let me know if its a
> known
> > issue or
> > > if I
> > > > am doing
> > > > > > something wrong.
> > > > > > > Regards.
> > > > > > > Tejaswini
> > > > > >
> > > > > > the reinstate command is supposed
> to
> > reinstate
> > > the
> > > > device
> > > > > with the
> > > > > > kernel, and it does that. The
> checker
> > state
> > > doesn't
> > > > change
> > > > > until the
> > > > > > next time that the path is
> checked. I
> > agree
> > > that it's
> > > > odd
> > > > > that the
> > > > > > check state switches to faulty as
> soon
> > as you
> > > fail the
> > > > path,
> > > > > but it
> > > > > > doesn't switch back until the
> next check
> > after
> > > you
> > > > reinistate
> > > > > it.
> > > > > >
> > > > > > The issue is that multipathd
> needs to
> > override
> > > the
> > > > checker
> > > > > output,
> > > > > > so that a failed path won't be
> > immeditately
> > > > reinstated. Once
> > > > > the
> > > > > > path comes back, multipathd wants
> to
> > record the
> > > switch
> > > > in the
> > > > > checker
> > > > > > thread, so that it can refresh
> path
> > information
> > > what
> > > > wasn't
> > > > > > automatically done when the path
> was
> > > reinstated.
> > > > However, it
> > > > > may make
> > > > > > more sense to have a different
> checker
> > state
> > > for when
> > > > the
> > > > > device is
> > > > > > in the failed state, so that it's
> > obvious that
> > > the
> > > > checker
> > > > > state is
> > > > > > being overruled.
> > > > > >
> > > > > > -Ben
> > > > > >
> > > > > > > --
> > > > > > > dm-devel mailing list
> > > > > > >
> [3][5][6][7][8][9]dm-devel@redhat.com
> > > > > > >
> > > >
> >
> [4][6][7][8][9][10]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > >
> > > > > > --
> > > > > > dm-devel mailing list
> > > > > >
> [5][7][8][9][10][11]dm-devel@redhat.com
> > > > > >
> > > >
> >
> [6][8][9][10][11][12]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1.
> > mailto:[9][10][11][12][13]tejaswinipoluri3@gmail.com
> > > > > > 2.
> > mailto:[10][11][12][13][14]bmarzins@redhat.com
> > > > > > 3.
> > mailto:[11][12][13][14][15]dm-devel@redhat.com
> > > > > > 4.
> > > >
> >
> [12][13][14][15][16]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > 5.
> > mailto:[13][14][15][16][17]dm-devel@redhat.com
> > > > > > 6.
> > > >
> >
> [14][15][16][17][18]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1.
> mailto:[16][17][18][19]tejaswinipoluri3@gmail.com
> > > > > 2. mailto:[17][18][19][20]bmarzins@redhat.com
> > > > > 3.
> mailto:[18][19][20][21]tejaswinipoluri3@gmail.com
> > > > > 4. mailto:[19][20][21][22]bmarzins@redhat.com
> > > > > 5. mailto:[20][21][22][23]dm-devel@redhat.com
> > > > > 6.
> > [21][22][23][24]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 7. mailto:[22][23][24][25]dm-devel@redhat.com
> > > > > 8.
> > [23][24][25][26]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 9.
> mailto:[24][25][26][27]tejaswinipoluri3@gmail.com
> > > > > 10. mailto:[25][26][27][28]bmarzins@redhat.com
> > > > > 11. mailto:[26][27][28][29]dm-devel@redhat.com
> > > > > 12.
> > [27][28][29][30]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 13. mailto:[28][29][30][31]dm-devel@redhat.com
> > > > > 14.
> > [29][30][31][32]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[31][32][33]bmarzins@redhat.com
> > > > 2. mailto:[32][33][34]tejaswinipoluri3@gmail.com
> > > > 3. mailto:[33][34][35]bmarzins@redhat.com
> > > > 4. mailto:[34][35][36]tejaswinipoluri3@gmail.com
> > > > 5. mailto:[35][36][37]bmarzins@redhat.com
> > > > 6. mailto:[36][37][38]dm-devel@redhat.com
> > > > 7.
> [37][38][39]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 8. mailto:[38][39][40]dm-devel@redhat.com
> > > > 9.
> [39][40][41]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 10. mailto:[40][41][42]tejaswinipoluri3@gmail.com
> > > > 11. mailto:[41][42][43]bmarzins@redhat.com
> > > > 12. mailto:[42][43][44]dm-devel@redhat.com
> > > > 13.
> [43][44][45]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 14. mailto:[44][45][46]dm-devel@redhat.com
> > > > 15.
> [45][46][47]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 16. mailto:[46][47][48]tejaswinipoluri3@gmail.com
> > > > 17. mailto:[47][48][49]bmarzins@redhat.com
> > > > 18. mailto:[48][49][50]tejaswinipoluri3@gmail.com
> > > > 19. mailto:[49][50][51]bmarzins@redhat.com
> > > > 20. mailto:[50][51][52]dm-devel@redhat.com
> > > > 21.
> [51][52][53]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 22. mailto:[52][53][54]dm-devel@redhat.com
> > > > 23.
> [53][54][55]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 24. mailto:[54][55][56]tejaswinipoluri3@gmail.com
> > > > 25. mailto:[55][56][57]bmarzins@redhat.com
> > > > 26. mailto:[56][57][58]dm-devel@redhat.com
> > > > 27.
> [57][58][59]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 28. mailto:[58][59][60]dm-devel@redhat.com
> > > > 29.
> [59][60][61]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[61][62]bmarzins@redhat.com
> > > 2. mailto:[62][63]bmarzins@redhat.com
> > > 3. mailto:[63][64]tejaswinipoluri3@gmail.com
> > > 4. mailto:[64][65]bmarzins@redhat.com
> > > 5. mailto:[65][66]tejaswinipoluri3@gmail.com
> > > 6. mailto:[66][67]bmarzins@redhat.com
> > > 7. mailto:[67][68]dm-devel@redhat.com
> > > 8. [68][69]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 9. mailto:[69][70]dm-devel@redhat.com
> > > 10. [70][71]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 11. mailto:[71][72]tejaswinipoluri3@gmail.com
> > > 12. mailto:[72][73]bmarzins@redhat.com
> > > 13. mailto:[73][74]dm-devel@redhat.com
> > > 14. [74][75]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 15. mailto:[75][76]dm-devel@redhat.com
> > > 16. [76][77]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 17. mailto:[77][78]tejaswinipoluri3@gmail.com
> > > 18. mailto:[78][79]bmarzins@redhat.com
> > > 19. mailto:[79][80]tejaswinipoluri3@gmail.com
> > > 20. mailto:[80][81]bmarzins@redhat.com
> > > 21. mailto:[81][82]dm-devel@redhat.com
> > > 22. [82][83]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 23. mailto:[83][84]dm-devel@redhat.com
> > > 24. [84][85]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 25. mailto:[85][86]tejaswinipoluri3@gmail.com
> > > 26. mailto:[86][87]bmarzins@redhat.com
> > > 27. mailto:[87][88]dm-devel@redhat.com
> > > 28. [88][89]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 29. mailto:[89][90]dm-devel@redhat.com
> > > 30. [90][91]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 31. mailto:[91][92]bmarzins@redhat.com
> > > 32. mailto:[92][93]tejaswinipoluri3@gmail.com
> > > 33. mailto:[93][94]bmarzins@redhat.com
> > > 34. mailto:[94][95]tejaswinipoluri3@gmail.com
> > > 35. mailto:[95][96]bmarzins@redhat.com
> > > 36. mailto:[96][97]dm-devel@redhat.com
> > > 37. [97][98]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 38. mailto:[98][99]dm-devel@redhat.com
> > > 39. [99][100]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 40. mailto:[100][101]tejaswinipoluri3@gmail.com
> > > 41. mailto:[101][102]bmarzins@redhat.com
> > > 42. mailto:[102][103]dm-devel@redhat.com
> > > 43.
> [103][104]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 44. mailto:[104][105]dm-devel@redhat.com
> > > 45.
> [105][106]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 46. mailto:[106][107]tejaswinipoluri3@gmail.com
> > > 47. mailto:[107][108]bmarzins@redhat.com
> > > 48. mailto:[108][109]tejaswinipoluri3@gmail.com
> > > 49. mailto:[109][110]bmarzins@redhat.com
> > > 50. mailto:[110][111]dm-devel@redhat.com
> > > 51.
> [111][112]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 52. mailto:[112][113]dm-devel@redhat.com
> > > 53.
> [113][114]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 54. mailto:[114][115]tejaswinipoluri3@gmail.com
> > > 55. mailto:[115][116]bmarzins@redhat.com
> > > 56. mailto:[116][117]dm-devel@redhat.com
> > > 57.
> [117][118]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 58. mailto:[118][119]dm-devel@redhat.com
> > > 59.
> [119][120]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:[121]bmarzins@redhat.com
> > 2. mailto:[122]bmarzins@redhat.com
> > 3. mailto:[123]bmarzins@redhat.com
> > 4. mailto:[124]tejaswinipoluri3@gmail.com
> > 5. mailto:[125]bmarzins@redhat.com
> > 6. mailto:[126]tejaswinipoluri3@gmail.com
> > 7. mailto:[127]bmarzins@redhat.com
> > 8. mailto:[128]dm-devel@redhat.com
> > 9. [129]https://www.redhat.com/mailman/listinfo/dm-devel
> > 10. mailto:[130]dm-devel@redhat.com
> > 11. [131]https://www.redhat.com/mailman/listinfo/dm-devel
> > 12. mailto:[132]tejaswinipoluri3@gmail.com
> > 13. mailto:[133]bmarzins@redhat.com
> > 14. mailto:[134]dm-devel@redhat.com
> > 15. [135]https://www.redhat.com/mailman/listinfo/dm-devel
> > 16. mailto:[136]dm-devel@redhat.com
> > 17. [137]https://www.redhat.com/mailman/listinfo/dm-devel
> > 18. mailto:[138]tejaswinipoluri3@gmail.com
> > 19. mailto:[139]bmarzins@redhat.com
> > 20. mailto:[140]tejaswinipoluri3@gmail.com
> > 21. mailto:[141]bmarzins@redhat.com
> > 22. mailto:[142]dm-devel@redhat.com
> > 23. [143]https://www.redhat.com/mailman/listinfo/dm-devel
> > 24. mailto:[144]dm-devel@redhat.com
> > 25. [145]https://www.redhat.com/mailman/listinfo/dm-devel
> > 26. mailto:[146]tejaswinipoluri3@gmail.com
> > 27. mailto:[147]bmarzins@redhat.com
> > 28. mailto:[148]dm-devel@redhat.com
> > 29. [149]https://www.redhat.com/mailman/listinfo/dm-devel
> > 30. mailto:[150]dm-devel@redhat.com
> > 31. [151]https://www.redhat.com/mailman/listinfo/dm-devel
> > 32. mailto:[152]bmarzins@redhat.com
> > 33. mailto:[153]tejaswinipoluri3@gmail.com
> > 34. mailto:[154]bmarzins@redhat.com
> > 35. mailto:[155]tejaswinipoluri3@gmail.com
> > 36. mailto:[156]bmarzins@redhat.com
> > 37. mailto:[157]dm-devel@redhat.com
> > 38. [158]https://www.redhat.com/mailman/listinfo/dm-devel
> > 39. mailto:[159]dm-devel@redhat.com
> > 40. [160]https://www.redhat.com/mailman/listinfo/dm-devel
> > 41. mailto:[161]tejaswinipoluri3@gmail.com
> > 42. mailto:[162]bmarzins@redhat.com
> > 43. mailto:[163]dm-devel@redhat.com
> > 44. [164]https://www.redhat.com/mailman/listinfo/dm-devel
> > 45. mailto:[165]dm-devel@redhat.com
> > 46. [166]https://www.redhat.com/mailman/listinfo/dm-devel
> > 47. mailto:[167]tejaswinipoluri3@gmail.com
> > 48. mailto:[168]bmarzins@redhat.com
> > 49. mailto:[169]tejaswinipoluri3@gmail.com
> > 50. mailto:[170]bmarzins@redhat.com
> > 51. mailto:[171]dm-devel@redhat.com
> > 52. [172]https://www.redhat.com/mailman/listinfo/dm-devel
> > 53. mailto:[173]dm-devel@redhat.com
> > 54. [174]https://www.redhat.com/mailman/listinfo/dm-devel
> > 55. mailto:[175]tejaswinipoluri3@gmail.com
> > 56. mailto:[176]bmarzins@redhat.com
> > 57. mailto:[177]dm-devel@redhat.com
> > 58. [178]https://www.redhat.com/mailman/listinfo/dm-devel
> > 59. mailto:[179]dm-devel@redhat.com
> > 60. [180]https://www.redhat.com/mailman/listinfo/dm-devel
> > 61. mailto:[181]bmarzins@redhat.com
> > 62. mailto:[182]bmarzins@redhat.com
> > 63. mailto:[183]tejaswinipoluri3@gmail.com
> > 64. mailto:[184]bmarzins@redhat.com
> > 65. mailto:[185]tejaswinipoluri3@gmail.com
> > 66. mailto:[186]bmarzins@redhat.com
> > 67. mailto:[187]dm-devel@redhat.com
> > 68. [188]https://www.redhat.com/mailman/listinfo/dm-devel
> > 69. mailto:[189]dm-devel@redhat.com
> > 70. [190]https://www.redhat.com/mailman/listinfo/dm-devel
> > 71. mailto:[191]tejaswinipoluri3@gmail.com
> > 72. mailto:[192]bmarzins@redhat.com
> > 73. mailto:[193]dm-devel@redhat.com
> > 74. [194]https://www.redhat.com/mailman/listinfo/dm-devel
> > 75. mailto:[195]dm-devel@redhat.com
> > 76. [196]https://www.redhat.com/mailman/listinfo/dm-devel
> > 77. mailto:[197]tejaswinipoluri3@gmail.com
> > 78. mailto:[198]bmarzins@redhat.com
> > 79. mailto:[199]tejaswinipoluri3@gmail.com
> > 80. mailto:[200]bmarzins@redhat.com
> > 81. mailto:[201]dm-devel@redhat.com
> > 82. [202]https://www.redhat.com/mailman/listinfo/dm-devel
> > 83. mailto:[203]dm-devel@redhat.com
> > 84. [204]https://www.redhat.com/mailman/listinfo/dm-devel
> > 85. mailto:[205]tejaswinipoluri3@gmail.com
> > 86. mailto:[206]bmarzins@redhat.com
> > 87. mailto:[207]dm-devel@redhat.com
> > 88. [208]https://www.redhat.com/mailman/listinfo/dm-devel
> > 89. mailto:[209]dm-devel@redhat.com
> > 90. [210]https://www.redhat.com/mailman/listinfo/dm-devel
> > 91. mailto:[211]bmarzins@redhat.com
> > 92. mailto:[212]tejaswinipoluri3@gmail.com
> > 93. mailto:[213]bmarzins@redhat.com
> > 94. mailto:[214]tejaswinipoluri3@gmail.com
> > 95. mailto:[215]bmarzins@redhat.com
> > 96. mailto:[216]dm-devel@redhat.com
> > 97. [217]https://www.redhat.com/mailman/listinfo/dm-devel
> > 98. mailto:[218]dm-devel@redhat.com
> > 99. [219]https://www.redhat.com/mailman/listinfo/dm-devel
> > 100. mailto:[220]tejaswinipoluri3@gmail.com
> > 101. mailto:[221]bmarzins@redhat.com
> > 102. mailto:[222]dm-devel@redhat.com
> > 103. [223]https://www.redhat.com/mailman/listinfo/dm-devel
> > 104. mailto:[224]dm-devel@redhat.com
> > 105. [225]https://www.redhat.com/mailman/listinfo/dm-devel
> > 106. mailto:[226]tejaswinipoluri3@gmail.com
> > 107. mailto:[227]bmarzins@redhat.com
> > 108. mailto:[228]tejaswinipoluri3@gmail.com
> > 109. mailto:[229]bmarzins@redhat.com
> > 110. mailto:[230]dm-devel@redhat.com
> > 111. [231]https://www.redhat.com/mailman/listinfo/dm-devel
> > 112. mailto:[232]dm-devel@redhat.com
> > 113. [233]https://www.redhat.com/mailman/listinfo/dm-devel
> > 114. mailto:[234]tejaswinipoluri3@gmail.com
> > 115. mailto:[235]bmarzins@redhat.com
> > 116. mailto:[236]dm-devel@redhat.com
> > 117. [237]https://www.redhat.com/mailman/listinfo/dm-devel
> > 118. mailto:[238]dm-devel@redhat.com
> > 119. [239]https://www.redhat.com/mailman/listinfo/dm-devel
>
> References
>
> Visible links
> 1. mailto:bmarzins@redhat.com
> 2. mailto:bmarzins@redhat.com
> 3. mailto:bmarzins@redhat.com
> 4. mailto:bmarzins@redhat.com
> 5. mailto:tejaswinipoluri3@gmail.com
> 6. mailto:bmarzins@redhat.com
> 7. mailto:tejaswinipoluri3@gmail.com
> 8. mailto:bmarzins@redhat.com
> 9. mailto:dm-devel@redhat.com
> 10. https://www.redhat.com/mailman/listinfo/dm-devel
> 11. mailto:dm-devel@redhat.com
> 12. https://www.redhat.com/mailman/listinfo/dm-devel
> 13. mailto:tejaswinipoluri3@gmail.com
> 14. mailto:bmarzins@redhat.com
> 15. mailto:dm-devel@redhat.com
> 16. https://www.redhat.com/mailman/listinfo/dm-devel
> 17. mailto:dm-devel@redhat.com
> 18. https://www.redhat.com/mailman/listinfo/dm-devel
> 19. mailto:tejaswinipoluri3@gmail.com
> 20. mailto:bmarzins@redhat.com
> 21. mailto:tejaswinipoluri3@gmail.com
> 22. mailto:bmarzins@redhat.com
> 23. mailto:dm-devel@redhat.com
> 24. https://www.redhat.com/mailman/listinfo/dm-devel
> 25. mailto:dm-devel@redhat.com
> 26. https://www.redhat.com/mailman/listinfo/dm-devel
> 27. mailto:tejaswinipoluri3@gmail.com
> 28. mailto:bmarzins@redhat.com
> 29. mailto:dm-devel@redhat.com
> 30. https://www.redhat.com/mailman/listinfo/dm-devel
> 31. mailto:dm-devel@redhat.com
> 32. https://www.redhat.com/mailman/listinfo/dm-devel
> 33. mailto:bmarzins@redhat.com
> 34. mailto:tejaswinipoluri3@gmail.com
> 35. mailto:bmarzins@redhat.com
> 36. mailto:tejaswinipoluri3@gmail.com
> 37. mailto:bmarzins@redhat.com
> 38. mailto:dm-devel@redhat.com
> 39. https://www.redhat.com/mailman/listinfo/dm-devel
> 40. mailto:dm-devel@redhat.com
> 41. https://www.redhat.com/mailman/listinfo/dm-devel
> 42. mailto:tejaswinipoluri3@gmail.com
> 43. mailto:bmarzins@redhat.com
> 44. mailto:dm-devel@redhat.com
> 45. https://www.redhat.com/mailman/listinfo/dm-devel
> 46. mailto:dm-devel@redhat.com
> 47. https://www.redhat.com/mailman/listinfo/dm-devel
> 48. mailto:tejaswinipoluri3@gmail.com
> 49. mailto:bmarzins@redhat.com
> 50. mailto:tejaswinipoluri3@gmail.com
> 51. mailto:bmarzins@redhat.com
> 52. mailto:dm-devel@redhat.com
> 53. https://www.redhat.com/mailman/listinfo/dm-devel
> 54. mailto:dm-devel@redhat.com
> 55. https://www.redhat.com/mailman/listinfo/dm-devel
> 56. mailto:tejaswinipoluri3@gmail.com
> 57. mailto:bmarzins@redhat.com
> 58. mailto:dm-devel@redhat.com
> 59. https://www.redhat.com/mailman/listinfo/dm-devel
> 60. mailto:dm-devel@redhat.com
> 61. https://www.redhat.com/mailman/listinfo/dm-devel
> 62. mailto:bmarzins@redhat.com
> 63. mailto:bmarzins@redhat.com
> 64. mailto:tejaswinipoluri3@gmail.com
> 65. mailto:bmarzins@redhat.com
> 66. mailto:tejaswinipoluri3@gmail.com
> 67. mailto:bmarzins@redhat.com
> 68. mailto:dm-devel@redhat.com
> 69. https://www.redhat.com/mailman/listinfo/dm-devel
> 70. mailto:dm-devel@redhat.com
> 71. https://www.redhat.com/mailman/listinfo/dm-devel
> 72. mailto:tejaswinipoluri3@gmail.com
> 73. mailto:bmarzins@redhat.com
> 74. mailto:dm-devel@redhat.com
> 75. https://www.redhat.com/mailman/listinfo/dm-devel
> 76. mailto:dm-devel@redhat.com
> 77. https://www.redhat.com/mailman/listinfo/dm-devel
> 78. mailto:tejaswinipoluri3@gmail.com
> 79. mailto:bmarzins@redhat.com
> 80. mailto:tejaswinipoluri3@gmail.com
> 81. mailto:bmarzins@redhat.com
> 82. mailto:dm-devel@redhat.com
> 83. https://www.redhat.com/mailman/listinfo/dm-devel
> 84. mailto:dm-devel@redhat.com
> 85. https://www.redhat.com/mailman/listinfo/dm-devel
> 86. mailto:tejaswinipoluri3@gmail.com
> 87. mailto:bmarzins@redhat.com
> 88. mailto:dm-devel@redhat.com
> 89. https://www.redhat.com/mailman/listinfo/dm-devel
> 90. mailto:dm-devel@redhat.com
> 91. https://www.redhat.com/mailman/listinfo/dm-devel
> 92. mailto:bmarzins@redhat.com
> 93. mailto:tejaswinipoluri3@gmail.com
> 94. mailto:bmarzins@redhat.com
> 95. mailto:tejaswinipoluri3@gmail.com
> 96. mailto:bmarzins@redhat.com
> 97. mailto:dm-devel@redhat.com
> 98. https://www.redhat.com/mailman/listinfo/dm-devel
> 99. mailto:dm-devel@redhat.com
> 100. https://www.redhat.com/mailman/listinfo/dm-devel
> 101. mailto:tejaswinipoluri3@gmail.com
> 102. mailto:bmarzins@redhat.com
> 103. mailto:dm-devel@redhat.com
> 104. https://www.redhat.com/mailman/listinfo/dm-devel
> 105. mailto:dm-devel@redhat.com
> 106. https://www.redhat.com/mailman/listinfo/dm-devel
> 107. mailto:tejaswinipoluri3@gmail.com
> 108. mailto:bmarzins@redhat.com
> 109. mailto:tejaswinipoluri3@gmail.com
> 110. mailto:bmarzins@redhat.com
> 111. mailto:dm-devel@redhat.com
> 112. https://www.redhat.com/mailman/listinfo/dm-devel
> 113. mailto:dm-devel@redhat.com
> 114. https://www.redhat.com/mailman/listinfo/dm-devel
> 115. mailto:tejaswinipoluri3@gmail.com
> 116. mailto:bmarzins@redhat.com
> 117. mailto:dm-devel@redhat.com
> 118. https://www.redhat.com/mailman/listinfo/dm-devel
> 119. mailto:dm-devel@redhat.com
> 120. https://www.redhat.com/mailman/listinfo/dm-devel
> 121. mailto:bmarzins@redhat.com
> 122. mailto:bmarzins@redhat.com
> 123. mailto:bmarzins@redhat.com
> 124. mailto:tejaswinipoluri3@gmail.com
> 125. mailto:bmarzins@redhat.com
> 126. mailto:tejaswinipoluri3@gmail.com
> 127. mailto:bmarzins@redhat.com
> 128. mailto:dm-devel@redhat.com
> 129. https://www.redhat.com/mailman/listinfo/dm-devel
> 130. mailto:dm-devel@redhat.com
> 131. https://www.redhat.com/mailman/listinfo/dm-devel
> 132. mailto:tejaswinipoluri3@gmail.com
> 133. mailto:bmarzins@redhat.com
> 134. mailto:dm-devel@redhat.com
> 135. https://www.redhat.com/mailman/listinfo/dm-devel
> 136. mailto:dm-devel@redhat.com
> 137. https://www.redhat.com/mailman/listinfo/dm-devel
> 138. mailto:tejaswinipoluri3@gmail.com
> 139. mailto:bmarzins@redhat.com
> 140. mailto:tejaswinipoluri3@gmail.com
> 141. mailto:bmarzins@redhat.com
> 142. mailto:dm-devel@redhat.com
> 143. https://www.redhat.com/mailman/listinfo/dm-devel
> 144. mailto:dm-devel@redhat.com
> 145. https://www.redhat.com/mailman/listinfo/dm-devel
> 146. mailto:tejaswinipoluri3@gmail.com
> 147. mailto:bmarzins@redhat.com
> 148. mailto:dm-devel@redhat.com
> 149. https://www.redhat.com/mailman/listinfo/dm-devel
> 150. mailto:dm-devel@redhat.com
> 151. https://www.redhat.com/mailman/listinfo/dm-devel
> 152. mailto:bmarzins@redhat.com
> 153. mailto:tejaswinipoluri3@gmail.com
> 154. mailto:bmarzins@redhat.com
> 155. mailto:tejaswinipoluri3@gmail.com
> 156. mailto:bmarzins@redhat.com
> 157. mailto:dm-devel@redhat.com
> 158. https://www.redhat.com/mailman/listinfo/dm-devel
> 159. mailto:dm-devel@redhat.com
> 160. https://www.redhat.com/mailman/listinfo/dm-devel
> 161. mailto:tejaswinipoluri3@gmail.com
> 162. mailto:bmarzins@redhat.com
> 163. mailto:dm-devel@redhat.com
> 164. https://www.redhat.com/mailman/listinfo/dm-devel
> 165. mailto:dm-devel@redhat.com
> 166. https://www.redhat.com/mailman/listinfo/dm-devel
> 167. mailto:tejaswinipoluri3@gmail.com
> 168. mailto:bmarzins@redhat.com
> 169. mailto:tejaswinipoluri3@gmail.com
> 170. mailto:bmarzins@redhat.com
> 171. mailto:dm-devel@redhat.com
> 172. https://www.redhat.com/mailman/listinfo/dm-devel
> 173. mailto:dm-devel@redhat.com
> 174. https://www.redhat.com/mailman/listinfo/dm-devel
> 175. mailto:tejaswinipoluri3@gmail.com
> 176. mailto:bmarzins@redhat.com
> 177. mailto:dm-devel@redhat.com
> 178. https://www.redhat.com/mailman/listinfo/dm-devel
> 179. mailto:dm-devel@redhat.com
> 180. https://www.redhat.com/mailman/listinfo/dm-devel
> 181. mailto:bmarzins@redhat.com
> 182. mailto:bmarzins@redhat.com
> 183. mailto:tejaswinipoluri3@gmail.com
> 184. mailto:bmarzins@redhat.com
> 185. mailto:tejaswinipoluri3@gmail.com
> 186. mailto:bmarzins@redhat.com
> 187. mailto:dm-devel@redhat.com
> 188. https://www.redhat.com/mailman/listinfo/dm-devel
> 189. mailto:dm-devel@redhat.com
> 190. https://www.redhat.com/mailman/listinfo/dm-devel
> 191. mailto:tejaswinipoluri3@gmail.com
> 192. mailto:bmarzins@redhat.com
> 193. mailto:dm-devel@redhat.com
> 194. https://www.redhat.com/mailman/listinfo/dm-devel
> 195. mailto:dm-devel@redhat.com
> 196. https://www.redhat.com/mailman/listinfo/dm-devel
> 197. mailto:tejaswinipoluri3@gmail.com
> 198. mailto:bmarzins@redhat.com
> 199. mailto:tejaswinipoluri3@gmail.com
> 200. mailto:bmarzins@redhat.com
> 201. mailto:dm-devel@redhat.com
> 202. https://www.redhat.com/mailman/listinfo/dm-devel
> 203. mailto:dm-devel@redhat.com
> 204. https://www.redhat.com/mailman/listinfo/dm-devel
> 205. mailto:tejaswinipoluri3@gmail.com
> 206. mailto:bmarzins@redhat.com
> 207. mailto:dm-devel@redhat.com
> 208. https://www.redhat.com/mailman/listinfo/dm-devel
> 209. mailto:dm-devel@redhat.com
> 210. https://www.redhat.com/mailman/listinfo/dm-devel
> 211. mailto:bmarzins@redhat.com
> 212. mailto:tejaswinipoluri3@gmail.com
> 213. mailto:bmarzins@redhat.com
> 214. mailto:tejaswinipoluri3@gmail.com
> 215. mailto:bmarzins@redhat.com
> 216. mailto:dm-devel@redhat.com
> 217. https://www.redhat.com/mailman/listinfo/dm-devel
> 218. mailto:dm-devel@redhat.com
> 219. https://www.redhat.com/mailman/listinfo/dm-devel
> 220. mailto:tejaswinipoluri3@gmail.com
> 221. mailto:bmarzins@redhat.com
> 222. mailto:dm-devel@redhat.com
> 223. https://www.redhat.com/mailman/listinfo/dm-devel
> 224. mailto:dm-devel@redhat.com
> 225. https://www.redhat.com/mailman/listinfo/dm-devel
> 226. mailto:tejaswinipoluri3@gmail.com
> 227. mailto:bmarzins@redhat.com
> 228. mailto:tejaswinipoluri3@gmail.com
> 229. mailto:bmarzins@redhat.com
> 230. mailto:dm-devel@redhat.com
> 231. https://www.redhat.com/mailman/listinfo/dm-devel
> 232. mailto:dm-devel@redhat.com
> 233. https://www.redhat.com/mailman/listinfo/dm-devel
> 234. mailto:tejaswinipoluri3@gmail.com
> 235. mailto:bmarzins@redhat.com
> 236. mailto:dm-devel@redhat.com
> 237. https://www.redhat.com/mailman/listinfo/dm-devel
> 238. mailto:dm-devel@redhat.com
> 239. https://www.redhat.com/mailman/listinfo/dm-devel
> commit 79ab9090d3fbcdb5844478419135d1390cf548c2
> Author: Tejaswini <tejaswinipoluri3@gmail.com>
> Date: Wed Jul 8 15:08:56 2015 +0530
>
> multipathd: Fixing add map functionality
>
> Add map feature of multipathd tools fails as the device
> is also been completely removed along with removing the map
> in the remove map code. So when add map is called we are
> creating the device again in kernel and doing add map
> using the coloasce_paths code.
>
> Signed-off-by: Tejaswini Poluri <tpoluri@mvista.com>
>
> diff --git a/multipathd/cli_handlers.c b/multipathd/cli_handlers.c
> index dc96c45..c54c767 100644
> --- a/multipathd/cli_handlers.c
> +++ b/multipathd/cli_handlers.c
> @@ -537,7 +537,7 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
> char dev_path[PATH_SIZE];
> char *alias;
> int rc;
> -
> + char *refwwid;
> param = convert_dev(param, 0);
> condlog(2, "%s: add map (operator)", param);
>
> @@ -547,6 +547,14 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
> condlog(2, "%s: map blacklisted", param);
> return 0;
> }
> + rc = get_refwwid(param, DEV_DEVMAP, vecs->pathvec, &refwwid);
> +
> + if (refwwid) {
> + condlog(2, "%s: add map (operator)", refwwid);
> + if(coalesce_paths(vecs, NULL, refwwid, 0))
> + condlog(2, "%s: coalesce-paths failed", param);
> + dm_lib_release();
> + }
> minor = dm_get_minor(param);
> if (minor < 0) {
> condlog(2, "%s: not a device mapper table", param);
> @@ -566,6 +574,7 @@ cli_add_map (void * v, char ** reply, int * len, void * data)
> }
> rc = ev_add_map(dev_path, alias, vecs);
> FREE(alias);
> + FREE(refwwid);
> return rc;
> }
>
> commit 910b4a82ec483b48eaf8b24eb3d7829273c690ed
> Author: Tejaswini <tejaswinipoluri3@gmail.com>
> Date: Wed Jul 8 17:18:03 2015 +0530
>
> multipathd: Disabled code that is not being used.
>
> This part of the code is moved to cli_add_map and
> disabled here as it is not used by any function call
> here.
>
> Signed-off-by: Tejaswini <tejaswinipoluri3@gmail.com>
>
> diff --git a/multipathd/main.c b/multipathd/main.c
> index f876258..060237c 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -329,6 +329,8 @@ ev_add_map (char * dev, char * alias, struct vectors * vecs)
> return 1;
> }
> }
> +#if 0 /*Disabled as the code is not being used by anyone.
> + TODO:confirm that no feature requires this code*/
> r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec, &refwwid);
>
> if (refwwid) {
> @@ -344,6 +346,7 @@ ev_add_map (char * dev, char * alias, struct vectors * vecs)
> condlog(0, "%s: uev_add_map %s failed", alias, dev);
>
> FREE(refwwid);
> +#endif
> return r;
> }
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: reinstate path not working
2015-07-10 16:06 ` Benjamin Marzinski
@ 2015-07-16 10:37 ` Tejaswini Poluri
0 siblings, 0 replies; 11+ messages in thread
From: Tejaswini Poluri @ 2015-07-16 10:37 UTC (permalink / raw)
To: Benjamin Marzinski; +Cc: device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 65953 bytes --]
Thanks a lot for the inputs. Sorry for the delay in updating (Got struck
with other issues)
Here is the cli_add_map function with the suggested changes and it seems to
work fine. Please have a look and suggest your inputs.
int
cli_add_map (void * v, char ** reply, int * len, void * data)
{
struct vectors * vecs = (struct vectors *)data;
char * param = get_keyparam(v, MAP);
int major, minor;
char dev_path[PATH_SIZE];
char *alias;
int rc;
char *refwwid;
param = convert_dev(param, 0);
condlog(2, "%s: add map (operator)", param);
if (filter_wwid(conf->blist_wwid, conf->elist_wwid, param, NULL)>0) {
*reply = strdup("blacklisted\n");
*len = strlen(*reply) + 1;
condlog(2, "%s: map blacklisted", param);
return 0;
}
mapname:
minor = dm_get_minor(param);
if (minor < 0) {
condlog(2, "%s: not a device mapper table", param);
//return 0;
}
major = dm_get_major(param);
if (major < 0) {
condlog(2, "%s: not a device mapper table", param);
//return 0;
}
sprintf(dev_path,"dm-%d", minor);
alias = dm_mapname(major, minor);
if (!alias) {
condlog(2, "%s: mapname not found for %d:%d",
param, major, minor);
rc = get_refwwid(param, DEV_DEVMAP, vecs->pathvec,
&refwwid);
if (refwwid) {
condlog(2, "%s: add map (operator)", refwwid);
if(coalesce_paths(vecs, NULL, refwwid, 0))
condlog(2, "%s: coalesce-paths failed",
param);
dm_lib_release();
}
goto mapname;
//return 0;
}
rc = ev_add_map(dev_path, alias, vecs);
FREE(alias);
FREE(refwwid);
return rc;
}
Regards,
Tejaswini
On Fri, Jul 10, 2015 at 9:36 PM, Benjamin Marzinski <bmarzins@redhat.com>
wrote:
> On Wed, Jul 08, 2015 at 05:31:26PM +0530, Tejaswini Poluri wrote:
> > Thanks a lot.
> > Can you guide me how to push upstream for the approval. Which branch
> > should I push to? Any list of testcases I should perform before I
> could
> > push?
>
> All you do is post it to dm-devel. I think it's easier for Christophe
> to pull the patches in, if you post them directly in the email. "git
> format-patch" and "git send-email" make this a lot faster.
>
> Please do whatever testing you feel is appropriate before posting.
>
> About the patches specifically: In cli_add_map(), wouldn't it make more
> sense to only do the coalesce_paths() if dm_mapname() fails. If it
> succeeds you clearly already have an existing map, so you don't need to
> create one.
>
> -Ben
>
> > I have created the following two patches. PFA
> > Regards,
> > Tejaswini
> > On Mon, Jul 6, 2015 at 11:15 PM, Benjamin Marzinski
> > <[1]bmarzins@redhat.com> wrote:
> >
> > On Tue, Jun 30, 2015 at 11:22:37AM +0530, Tejaswini Poluri wrote:
> > > Thanks Ben. So should I push the code to the upstream and get
> an
> > approval?
> > > Regards,
> >
> > Yes. Thanks!
> >
> > -Ben
> > > Tejaswini
> > > On Tue, Jun 30, 2015 at 12:50 AM, Benjamin Marzinski
> > > <[1][2]bmarzins@redhat.com> wrote:
> > >
> > > On Fri, Jun 26, 2015 at 12:21:48PM +0530, Tejaswini Poluri
> wrote:
> > > > Yes I agree that having the same code in both
> cli_add_map()
> > and
> > > ev_add_map
> > > > is not necessary. Hence I would suggest removing
> > get_refwwid() code
> > > from
> > > > ev_add_map as it is not being used by anyone.
> > > >
> > > > ev_add_map(param, NULL, vecs) would create the multipath
> > device by
> > > using
> > > > the get_refwwid() code and but all the functions above
> it
> > like
> > > > (dm_get_minor, dm_get_major and dm_mapname) would fail
> and
> > it
> > > wouldn't
> > > > enter any of the other code in ev_add_map like
> > > > 1.dm_map_present,
> > > > 2.add_map_without_path
> > > > 3. sync_map_state
> > > > which are responsible for registering the map and
> displaying
> > it.
> > > >
> > > > So, I think moving the below code from ev_add_map to
> > cli_add_map
> > > should be
> > > > a good idea right.
> > > >
> > > > r = get_refwwid(dev, DEV_DEVMAP,
> vecs->pathvec,&refwwid);
> > > > >
> > > > > if (refwwid) {
> > > > > r = coalesce_paths(vecs, NULL,
> > refwwid,0);
> > > > > dm_lib_release();
> > > > > }
> > > > What do u think?
> > >
> > > I agree. We aren't using the code in ev_add_map, so it's
> presence
> > there
> > > is simply confusing.
> > >
> > > -Ben
> > > >
> > > > Regards,
> > > > Tejaswini
> > > > On Fri, Jun 26, 2015 at 4:32 AM, Benjamin Marzinski
> > > > <[1][2][3]bmarzins@redhat.com> wrote:
> > > >
> > > > On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini
> Poluri
> > wrote:
> > > > > Hi Ben,
> > > > >
> > > > > This is regarding the add map issue I have been
> > discussing.
> > > Posting
> > > > the
> > > > > issue again to remind.
> > > > >
> > > > > Case 1 : remove and add map.
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > name sysfs uuid
> > > > > dmpath0 dm-0 1IET_00010001
> > > > > root@x86-generic-64:~# multipathd -k'remove map
> > dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~# multipathd -k'add map
> dmpath0'
> > > > > ok
> > > > > root@x86-generic-64:~# multipathd -k'show maps'
> > > > > root@x86-generic-64:~#
> > > > > Once a map is removed, we are able to add it only
> > using
> > > #multipath
> > > > > command and not using multipathd tools.
> > > > >
> > > > > I have fixed the problem with two approaches. I
> would
> > like
> > > you to
> > > > review
> > > > > the same.
> > > > > Patch1 : By making 'remove map dmpath0' to remove
> > only the
> > > map and
> > > > not the
> > > > > device. I have added extra functions discard_map
> and
> > > dm_remove_map
> > > > so as
> > > > > to not interfere with the existing code.
> > > > >
> > > > > Patch 2: The approach you have suggested.By
> getting
> > wwid
> > > from the
> > > > mapname
> > > > > and doing coalesce_paths. I have just moved the
> > following
> > > code in
> > > > > ev_add_map to cli_add_map.
> > > >
> > > > This is the general idea we'd like to go with.
> However,
> > looking
> > > at the
> > > > latest upstream code, I don't think you should pull
> code
> > in from
> > > > ev_add_map() to cli_add_map() like your patch does.
> > cli_add_map()
> > > > already calls ev_add_map(), and ev_add_map() is
> certainly
> > able to
> > > add
> > > > the map if it doesn't already exist.
> > > >
> > > > You would just need to call it with
> > > >
> > > > ev_add_map(param, NULL, vecs);
> > > >
> > > > and ev_add_map() will happily create you a new
> multipath
> > device.
> > > All
> > > > you need to do is make sure that all the functions
> that
> > > ev_add_map()
> > > > calls with alias can accept a NULL value there.
> > > >
> > > > This might not be the best way to go about this,
> however.
> > It
> > > turns out
> > > > that right now, even though ev_add_map() technically
> has
> > the
> > > ability to
> > > > create new maps, nothing currently uses it, and it
> really
> > doesn't
> > > make
> > > > sense for it to be there. Instead of just copying that
> > code, you
> > > could
> > > > pull the map creation code out of ev_add_map() and
> add it
> > to
> > > > cli_add_map(), for those situations where the
> requested
> > device
> > > doesn't
> > > > already exist.
> > > >
> > > > But having the code in both cli_add_map() and
> ev_add_map()
> > when
> > > one
> > > > already calls the other doesn't seem necessary.
> > > >
> > > > -Ben
> > > >
> > > > >
> > > > > r = get_refwwid(dev, DEV_DEVMAP,
> > vecs->pathvec,&refwwid);
> > > > >
> > > > > if (refwwid) {
> > > > > r = coalesce_paths(vecs, NULL,
> > refwwid,0);
> > > > > dm_lib_release();
> > > > > }
> > > > >
> > > > > changed dev to param.
> > > > >
> > > > > I have tested the same in all 3 versions -0.4.8,
> > 0.4.9 and
> > > 0.5.0.
> > > > It would
> > > > > be great if you can review the same so that it
> > doesn't cause
> > > any
> > > > extra
> > > > > side effects.
> > > > > I guess Patch2 is the way u have suggested me in
> the
> > > previous mail.
> > > > Please
> > > > > review it and share your views.
> > > > > Regards,
> > > > > Tejaswini
> > > > > On Fri, Jun 12, 2015 at 2:21 AM, Benjamin
> Marzinski
> > > > > <[1][2][3][4]bmarzins@redhat.com> wrote:
> > > > >
> > > > > On Wed, Jun 10, 2015 at 11:46:51AM +0530,
> Tejaswini
> > Poluri
> > > wrote:
> > > > > >
> > > > > > > We are testing multipathd tools with
> all
> > the
> > > possible
> > > > options
> > > > > and the
> > > > > > > following fails.
> > > > > > >
> > > > > > > Case 1 : remove and add map.
> > > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > > name sysfs uuid
> > > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > > root@x86-generic-64:~# multipathd
> > -k'remove map
> > > > dmpath0'
> > > > > > > ok
> > > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > > root@x86-generic-64:~# multipathd
> -k'add
> > map
> > > dmpath0'
> > > > > > > ok
> > > > > > > root@x86-generic-64:~# multipathd
> -k'show
> > maps'
> > > > > > > root@x86-generic-64:~#
> > > > > > > Once a map is removed, we are able
> to add
> > it
> > > only using
> > > > > #multipath
> > > > > > > command and not using multipathd
> tools.
> > > > > >
> > > > > > It is working the way it was designed, but
> > possibly
> > > it would
> > > > make
> > > > > sense
> > > > > > to change the design.
> > > > > >
> > > > > > You have mentioned that it would make
> sense to
> > change
> > > the
> > > > design to
> > > > > add
> > > > > > map. Are there plans to change the design
> ?
> > > > > > I am trying to understand the code flow to
> > change the
> > > > design. Can
> > > > > you
> > > > > > guide me if we should stop removing the
> device
> > from
> > > in the
> > > > remove
> > > > > map code
> > > > > > flow or start adding the device and the
> map in
> > the
> > > add map
> > > > code
> > > > > flow.
> > > > > >
> > > > > > have tried to understand the remove map
> code
> > flow of
> > > > multipathd in
> > > > > 0.4.8
> > > > > > code.
> > > > >
> > > > > I think that we want multipath to actually
> remove
> > the map
> > > > (instead of
> > > > > just not monitoring it) when you call "remove
> map
> > <map>".
> > > We just
> > > > want
> > > > > "add map <map>" to try to create the map if it
> > doesn't
> > > exist. To
> > > > do
> > > > > that, you would need to first firgure out what
> WWID
> > is
> > > associated
> > > > with
> > > > > <map>. Presumably, <map> could either be an
> alias,
> > wwid,
> > > or even
> > > > the
> > > > > name of a path in the map. Once you found the
> map,
> > you
> > > would have
> > > > to
> > > > > call the code to create the map.
> > > > >
> > > > > Also, to answer your IRC question, no the 0.4.8
> > code is
> > > not still
> > > > being
> > > > > developed upstream. All upstream patches only
> go
> > against
> > > the
> > > > current
> > > > > head. There are no other upstream branches.
> > > > >
> > > > > -Ben
> > > > > >
> > > > > > ev_remove_map (char * devname, struct
> vectors
> > * vecs)
> > > > > >
> > > > > > flush_map(mpp, vecs);
> > > > > >
> > > > > >
> > dm_flush_map(mpp->alias,
> > > > DEFAULT_TARGET);
> > > > > >
> > > > > > if
> > > > (!dm_map_present(mapname))
> > > > > >
> > > > > >
> return
> > 0;
> > > > > >
> > > > > > if (dm_type(mapname, type) <= 0)
> > > > > >
> > > > > > return 1;
> > > > > >
> > > > > > if (dm_remove_partmaps(mapname))
> > > > > >
> > > > > > return 1;
> > > > > >
> > > > > > if (dm_get_opencount(mapname)) {
> > > > > >
> > > > > > condlog(2, "%s: map in
> use",
> > mapname);
> > > > > >
> > > > > > return 1;
> > > > > >
> > > > > > }
> > > > > >
> > > > > > r = dm_simplecmd(DM_DEVICE_REMOVE,
> > mapname);
> > > > > >
> > > > > > if (r) {
> > > > > >
> > > > > > condlog(4, "multipath map
> %s
> > removed",
> > > > mapname);
> > > > > >
> > > > > >
>
> > return
> > > 0;
> > > > > >
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > orphan_paths(vecs->pathvec,
> > > mpp);
> > > > > >
> > > > > > remove_map(mpp,
> vecs,
> > > > stop_waiter_thread,
> > > > > 1);
> > > > > >
> > > > > > Is removing this below line, the right
> step to
> > stop
> > > removing
> > > > the
> > > > > device ?
> > > > > > r = dm_simplecmd(DM_DEVICE_REMOVE,
> mapname);
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Tejaswini
> > > > > >
> > > > > > On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini
> > Poluri
> > > > > > <[1][2][3][4][5]
> tejaswinipoluri3@gmail.com>
> > wrote:
> > > > > >
> > > > > > Thanks a lot Ben for the quick and
> detailed
> > reply.
> > > I have
> > > > been
> > > > > > struggling to understand and conclude
> the
> > issues
> > > with
> > > > multipath
> > > > > as I am
> > > > > > the only one working from my team. Your
> > inputs help
> > > me a
> > > > lot.
> > > > > Thanks
> > > > > > again.
> > > > > > Regards,
> > > > > > Tejaswini
> > > > > > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin
> > Marzinski
> > > > > > <[2][3][4][5][6]bmarzins@redhat.com>
> wrote:
> > > > > >
> > > > > > On Fri, Jun 05, 2015 at 02:31:20PM
> +0530,
> > > Tejaswini
> > > > Poluri
> > > > > wrote:
> > > > > > > Hii Ben,
> > > > > > >
> > > > > > > We are testing multipathd tools
> with
> > all the
> > > > possible
> > > > > options and
> > > > > > the
> > > > > > > following fails.
> > > > > > >
> > > > > > > Case 1 : remove and add map.
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k'show
> > > maps'
> > > > > > > name sysfs uuid
> > > > > > > dmpath0 dm-0 1IET_00010001
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k'remove
> > > map
> > > > dmpath0'
> > > > > > > ok
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k'show
> > > maps'
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k'add map
> > > > dmpath0'
> > > > > > > ok
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k'show
> > > maps'
> > > > > > > root@x86-generic-64:~#
> > > > > > > Once a map is removed, we are
> able to
> > add it
> > > only
> > > > using
> > > > > > #multipath
> > > > > > > command and not using multipathd
> > tools.
> > > > > >
> > > > > > It is working the way it was
> designed, but
> > > possibly it
> > > > would
> > > > > make
> > > > > > sense
> > > > > > to change the design. The "remove
> map"
> > command,
> > > not
> > > > only stops
> > > > > > multipathd from monitoring the
> multipath
> > device,
> > > but it
> > > > removes
> > > > > it
> > > > > > from
> > > > > > the system as well. The "add map"
> command
> > makes
> > > > multipath
> > > > > monitor an
> > > > > > already existing multipath device
> that in
> > wasn't
> > > > previously
> > > > > > monitoring.
> > > > > > These commands do this for historical
> > reasons.
> > > > multipathd
> > > > > wasn't
> > > > > > originally in charge of creating
> multipath
> > > devices,
> > > > multipath
> > > > > was.
> > > > > > Once
> > > > > > it had created the device, it ran
> > > > > >
> > > > > > multipathd -k"add map <MAP>"
> > > > > >
> > > > > > to make multipathd start monitoring
> it.
> > However
> > > things
> > > > haven't
> > > > > worked
> > > > > > this way since RHEL4, so possibly "add
> > map"
> > > should
> > > > actually
> > > > > create the
> > > > > > device if it doesn't currently exist.
> > > > > > > Case 2 : Active paths test case
> > > > > > > # while true ; do sleep 3 ;
> > multipathd
> > > -k'remove
> > > > path sdb'
> > > > > ;
> > > > > > multipathd
> > > > > > > -k'add path sdb' ; multipathd
> -k'show
> > maps
> > > status'
> > > > ; done
> > > > > > > ok
> > > > > > > ok
> > > > > > > name failback queueing paths
> dm-st
> > > > > > > dmpath0 - - 1 active // It
> should be
> > 2.
> > > > > >
> > > > > > This is simply a timing issue. What
> you
> > are
> > > seeing it
> > > > the
> > > > > number of
> > > > > > active paths. These are paths that
> the
> > kernel
> > > can use.
> > > > The
> > > > > "add path"
> > > > > > command doesn't update the kernel
> state.
> > This
> > > happens
> > > > later in
> > > > > > response
> > > > > > to the kernel reloading the device
> table.
> > So, in
> > > a
> > > > second or
> > > > > two, this
> > > > > > will say 2, as expected.
> > > > > >
> > > > > > > We would like to know if the test
> > cases are
> > > valid
> > > > and if
> > > > > these
> > > > > > are bugs or
> > > > > > > any design issues.
> > > > > > >
> > > > > > > Case 3 : Fail path and reinstate
> path
> > > > > > > root@x86-generic-64:~#
> multipathd
> > -k"fail
> > > path
> > > > sdc";
> > > > > multipathd
> > > > > > > -k'reinstate path sdc';
> multipathd
> > -k"show
> > > paths";
> > > > > > > > [ 3962.708523]
> device-mapper:
> > > multipath:
> > > > Failing path
> > > > > 8:32.
> > > > > > > > ok
> > > > > > > > ok
> > > > > > > > hcil dev dev_t pri
> dm_st
> > chk_st
> > > > next_check
> > > > > > > > 4:0:0:1 sdc 8:32 1
> > [active][faulty]
> > > > ..........
> > > > > 1/20
> > > > > > <==CHECK
> > > > > > > > 5:0:0:1 sdd 8:48 1
> > [active][ready]
> > > > XX........
> > > > > 4/20
> > > > > > > sdc path becomes [active][ready]
> only
> > after
> > > the
> > > > polling
> > > > > interval
> > > > > > but not
> > > > > > > immediately after the reinstate
> path
> > > command.
> > > > > > > You have answered that this is a
> > design
> > > issue. But
> > > > we have
> > > > > heard
> > > > > > from our
> > > > > > > test team that the same test case
> > works in
> > > RHEL6.
> > > > Did you
> > > > > observe
> > > > > > it?
> > > > > > > I am also finding that the test
> cases
> > fail
> > > because
> > > > we are
> > > > > trying
> > > > > > to do
> > > > > > > multiple commands at one shot.
> > Please share
> > > your
> > > > thoughts
> > > > > so
> > > > > > that it
> > > > > > > could help me in debugging the
> issues
> > > further.
> > > > > > >
> > > > > >
> > > > > > It's totally possible that the checker
> > state is
> > > > immediately
> > > > > updated in
> > > > > > RHEL6. Like I said before, what it
> > currently
> > > does,
> > > > although
> > > > > correct,
> > > > > > is confusing, and perhaps we need a
> > different
> > > checker
> > > > state for
> > > > > paths
> > > > > > where the "fail path" command has been
> > used.
> > > > > >
> > > > > > -Ben
> > > > > > > Regards,
> > > > > > > Tejaswini
> > > > > > > On Tue, May 19, 2015 at 5:37 PM,
> > Tejaswini
> > > Poluri
> > > > > > >
> > <[1][3][4][5][6][7]tejaswinipoluri3@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > Thanks a lot Ben. I will look
> into
> > it
> > > more.
> > > > > > > On Mon, May 18, 2015 at 9:57
> PM,
> > Benjamin
> > > > Marzinski
> > > > > > >
> > <[2][4][5][6][7][8]bmarzins@redhat.com>
> > > wrote:
> > > > > > >
> > > > > > > On Mon, May 18, 2015 at
> > 02:09:27PM
> > > +0530,
> > > > Tejaswini
> > > > > Poluri
> > > > > > wrote:
> > > > > > > > Hii,
> > > > > > > > We are trying to test
> > multipath
> > > setup in
> > > > our
> > > > > target and
> > > > > > tried the
> > > > > > > various
> > > > > > > > commands of multipathd
> > demaon and
> > > we find
> > > > the
> > > > > following
> > > > > > error:
> > > > > > > > root@x86-generic-64:~#
> > multipathd
> > > -k"fail
> > > > path
> > > > > sdc";
> > > > > > multipathd
> > > > > > > > -k'reinstate path
> > > > > > > > sdc'; multipathd -k"show
> > paths";
> > > > > > > > [ 3962.708523]
> > device-mapper:
> > > multipath:
> > > > Failing
> > > > > > path 8:32.
> > > > > > > > ok
> > > > > > > > ok
> > > > > > > > hcil dev dev_t pri
> dm_st
> > > chk_st
> > > > next_check
> > > > > > > > 4:0:0:1 sdc 8:32 1
> > > [active][faulty]
> > > > ..........
> > > > > 1/20
> > > > > > <<<===
> > > > > > > CHECK
> > > > > > > > 5:0:0:1 sdd 8:48 1
> > > [active][ready]
> > > > XX........
> > > > > 4/20
> > > > > > > > sdc path becomes
> > [active][ready]
> > > only
> > > > after the
> > > > > polling
> > > > > > interval
> > > > > > > but not
> > > > > > > > immediately after the
> > reinstate
> > > path
> > > > command.
> > > > > > > > I am observing this in
> > latest
> > > multipath
> > > > tools in
> > > > > ubuntu
> > > > > > machine
> > > > > > > as well.
> > > > > > > > Please let me know if
> its a
> > known
> > > issue or
> > > > if I
> > > > > am doing
> > > > > > > something wrong.
> > > > > > > > Regards.
> > > > > > > > Tejaswini
> > > > > > >
> > > > > > > the reinstate command is
> supposed
> > to
> > > reinstate
> > > > the
> > > > > device
> > > > > > with the
> > > > > > > kernel, and it does that. The
> > checker
> > > state
> > > > doesn't
> > > > > change
> > > > > > until the
> > > > > > > next time that the path is
> > checked. I
> > > agree
> > > > that it's
> > > > > odd
> > > > > > that the
> > > > > > > check state switches to
> faulty as
> > soon
> > > as you
> > > > fail the
> > > > > path,
> > > > > > but it
> > > > > > > doesn't switch back until the
> > next check
> > > after
> > > > you
> > > > > reinistate
> > > > > > it.
> > > > > > >
> > > > > > > The issue is that multipathd
> > needs to
> > > override
> > > > the
> > > > > checker
> > > > > > output,
> > > > > > > so that a failed path won't
> be
> > > immeditately
> > > > > reinstated. Once
> > > > > > the
> > > > > > > path comes back, multipathd
> wants
> > to
> > > record the
> > > > switch
> > > > > in the
> > > > > > checker
> > > > > > > thread, so that it can
> refresh
> > path
> > > information
> > > > what
> > > > > wasn't
> > > > > > > automatically done when the
> path
> > was
> > > > reinstated.
> > > > > However, it
> > > > > > may make
> > > > > > > more sense to have a
> different
> > checker
> > > state
> > > > for when
> > > > > the
> > > > > > device is
> > > > > > > in the failed state, so that
> it's
> > > obvious that
> > > > the
> > > > > checker
> > > > > > state is
> > > > > > > being overruled.
> > > > > > >
> > > > > > > -Ben
> > > > > > >
> > > > > > > > --
> > > > > > > > dm-devel mailing list
> > > > > > > >
> > [3][5][6][7][8][9]dm-devel@redhat.com
> > > > > > > >
> > > > >
> > >
> > [4][6][7][8][9][10]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > >
> > > > > > > --
> > > > > > > dm-devel mailing list
> > > > > > >
> > [5][7][8][9][10][11]dm-devel@redhat.com
> > > > > > >
> > > > >
> > >
> > [6][8][9][10][11][12]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > >
> > > > > > > References
> > > > > > >
> > > > > > > Visible links
> > > > > > > 1.
> > > mailto:[9][10][11][12][13]tejaswinipoluri3@gmail.com
> > > > > > > 2.
> > > mailto:[10][11][12][13][14]bmarzins@redhat.com
> > > > > > > 3.
> > > mailto:[11][12][13][14][15]dm-devel@redhat.com
> > > > > > > 4.
> > > > >
> > >
> > [12][13][14][15][16]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > > 5.
> > > mailto:[13][14][15][16][17]dm-devel@redhat.com
> > > > > > > 6.
> > > > >
> > >
> > [14][15][16][17][18]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1.
> > mailto:[16][17][18][19]tejaswinipoluri3@gmail.com
> > > > > > 2. mailto:[17][18][19][20]
> bmarzins@redhat.com
> > > > > > 3.
> > mailto:[18][19][20][21]tejaswinipoluri3@gmail.com
> > > > > > 4. mailto:[19][20][21][22]
> bmarzins@redhat.com
> > > > > > 5. mailto:[20][21][22][23]
> dm-devel@redhat.com
> > > > > > 6.
> > > [21][22][23][24]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > 7. mailto:[22][23][24][25]
> dm-devel@redhat.com
> > > > > > 8.
> > > [23][24][25][26]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > 9.
> > mailto:[24][25][26][27]tejaswinipoluri3@gmail.com
> > > > > > 10. mailto:[25][26][27][28]
> bmarzins@redhat.com
> > > > > > 11. mailto:[26][27][28][29]
> dm-devel@redhat.com
> > > > > > 12.
> > > [27][28][29][30]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > > 13. mailto:[28][29][30][31]
> dm-devel@redhat.com
> > > > > > 14.
> > > [29][30][31][32]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1. mailto:[31][32][33]bmarzins@redhat.com
> > > > > 2. mailto:[32][33][34]tejaswinipoluri3@gmail.com
> > > > > 3. mailto:[33][34][35]bmarzins@redhat.com
> > > > > 4. mailto:[34][35][36]tejaswinipoluri3@gmail.com
> > > > > 5. mailto:[35][36][37]bmarzins@redhat.com
> > > > > 6. mailto:[36][37][38]dm-devel@redhat.com
> > > > > 7.
> > [37][38][39]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 8. mailto:[38][39][40]dm-devel@redhat.com
> > > > > 9.
> > [39][40][41]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 10. mailto:[40][41][42]tejaswinipoluri3@gmail.com
> > > > > 11. mailto:[41][42][43]bmarzins@redhat.com
> > > > > 12. mailto:[42][43][44]dm-devel@redhat.com
> > > > > 13.
> > [43][44][45]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 14. mailto:[44][45][46]dm-devel@redhat.com
> > > > > 15.
> > [45][46][47]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 16. mailto:[46][47][48]tejaswinipoluri3@gmail.com
> > > > > 17. mailto:[47][48][49]bmarzins@redhat.com
> > > > > 18. mailto:[48][49][50]tejaswinipoluri3@gmail.com
> > > > > 19. mailto:[49][50][51]bmarzins@redhat.com
> > > > > 20. mailto:[50][51][52]dm-devel@redhat.com
> > > > > 21.
> > [51][52][53]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 22. mailto:[52][53][54]dm-devel@redhat.com
> > > > > 23.
> > [53][54][55]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 24. mailto:[54][55][56]tejaswinipoluri3@gmail.com
> > > > > 25. mailto:[55][56][57]bmarzins@redhat.com
> > > > > 26. mailto:[56][57][58]dm-devel@redhat.com
> > > > > 27.
> > [57][58][59]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 28. mailto:[58][59][60]dm-devel@redhat.com
> > > > > 29.
> > [59][60][61]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[61][62]bmarzins@redhat.com
> > > > 2. mailto:[62][63]bmarzins@redhat.com
> > > > 3. mailto:[63][64]tejaswinipoluri3@gmail.com
> > > > 4. mailto:[64][65]bmarzins@redhat.com
> > > > 5. mailto:[65][66]tejaswinipoluri3@gmail.com
> > > > 6. mailto:[66][67]bmarzins@redhat.com
> > > > 7. mailto:[67][68]dm-devel@redhat.com
> > > > 8. [68][69]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 9. mailto:[69][70]dm-devel@redhat.com
> > > > 10. [70][71]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 11. mailto:[71][72]tejaswinipoluri3@gmail.com
> > > > 12. mailto:[72][73]bmarzins@redhat.com
> > > > 13. mailto:[73][74]dm-devel@redhat.com
> > > > 14. [74][75]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 15. mailto:[75][76]dm-devel@redhat.com
> > > > 16. [76][77]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 17. mailto:[77][78]tejaswinipoluri3@gmail.com
> > > > 18. mailto:[78][79]bmarzins@redhat.com
> > > > 19. mailto:[79][80]tejaswinipoluri3@gmail.com
> > > > 20. mailto:[80][81]bmarzins@redhat.com
> > > > 21. mailto:[81][82]dm-devel@redhat.com
> > > > 22. [82][83]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 23. mailto:[83][84]dm-devel@redhat.com
> > > > 24. [84][85]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 25. mailto:[85][86]tejaswinipoluri3@gmail.com
> > > > 26. mailto:[86][87]bmarzins@redhat.com
> > > > 27. mailto:[87][88]dm-devel@redhat.com
> > > > 28. [88][89]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 29. mailto:[89][90]dm-devel@redhat.com
> > > > 30. [90][91]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 31. mailto:[91][92]bmarzins@redhat.com
> > > > 32. mailto:[92][93]tejaswinipoluri3@gmail.com
> > > > 33. mailto:[93][94]bmarzins@redhat.com
> > > > 34. mailto:[94][95]tejaswinipoluri3@gmail.com
> > > > 35. mailto:[95][96]bmarzins@redhat.com
> > > > 36. mailto:[96][97]dm-devel@redhat.com
> > > > 37. [97][98]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 38. mailto:[98][99]dm-devel@redhat.com
> > > > 39. [99][100]
> https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 40. mailto:[100][101]tejaswinipoluri3@gmail.com
> > > > 41. mailto:[101][102]bmarzins@redhat.com
> > > > 42. mailto:[102][103]dm-devel@redhat.com
> > > > 43.
> > [103][104]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 44. mailto:[104][105]dm-devel@redhat.com
> > > > 45.
> > [105][106]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 46. mailto:[106][107]tejaswinipoluri3@gmail.com
> > > > 47. mailto:[107][108]bmarzins@redhat.com
> > > > 48. mailto:[108][109]tejaswinipoluri3@gmail.com
> > > > 49. mailto:[109][110]bmarzins@redhat.com
> > > > 50. mailto:[110][111]dm-devel@redhat.com
> > > > 51.
> > [111][112]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 52. mailto:[112][113]dm-devel@redhat.com
> > > > 53.
> > [113][114]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 54. mailto:[114][115]tejaswinipoluri3@gmail.com
> > > > 55. mailto:[115][116]bmarzins@redhat.com
> > > > 56. mailto:[116][117]dm-devel@redhat.com
> > > > 57.
> > [117][118]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 58. mailto:[118][119]dm-devel@redhat.com
> > > > 59.
> > [119][120]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[121]bmarzins@redhat.com
> > > 2. mailto:[122]bmarzins@redhat.com
> > > 3. mailto:[123]bmarzins@redhat.com
> > > 4. mailto:[124]tejaswinipoluri3@gmail.com
> > > 5. mailto:[125]bmarzins@redhat.com
> > > 6. mailto:[126]tejaswinipoluri3@gmail.com
> > > 7. mailto:[127]bmarzins@redhat.com
> > > 8. mailto:[128]dm-devel@redhat.com
> > > 9. [129]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 10. mailto:[130]dm-devel@redhat.com
> > > 11. [131]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 12. mailto:[132]tejaswinipoluri3@gmail.com
> > > 13. mailto:[133]bmarzins@redhat.com
> > > 14. mailto:[134]dm-devel@redhat.com
> > > 15. [135]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 16. mailto:[136]dm-devel@redhat.com
> > > 17. [137]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 18. mailto:[138]tejaswinipoluri3@gmail.com
> > > 19. mailto:[139]bmarzins@redhat.com
> > > 20. mailto:[140]tejaswinipoluri3@gmail.com
> > > 21. mailto:[141]bmarzins@redhat.com
> > > 22. mailto:[142]dm-devel@redhat.com
> > > 23. [143]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 24. mailto:[144]dm-devel@redhat.com
> > > 25. [145]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 26. mailto:[146]tejaswinipoluri3@gmail.com
> > > 27. mailto:[147]bmarzins@redhat.com
> > > 28. mailto:[148]dm-devel@redhat.com
> > > 29. [149]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 30. mailto:[150]dm-devel@redhat.com
> > > 31. [151]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 32. mailto:[152]bmarzins@redhat.com
> > > 33. mailto:[153]tejaswinipoluri3@gmail.com
> > > 34. mailto:[154]bmarzins@redhat.com
> > > 35. mailto:[155]tejaswinipoluri3@gmail.com
> > > 36. mailto:[156]bmarzins@redhat.com
> > > 37. mailto:[157]dm-devel@redhat.com
> > > 38. [158]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 39. mailto:[159]dm-devel@redhat.com
> > > 40. [160]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 41. mailto:[161]tejaswinipoluri3@gmail.com
> > > 42. mailto:[162]bmarzins@redhat.com
> > > 43. mailto:[163]dm-devel@redhat.com
> > > 44. [164]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 45. mailto:[165]dm-devel@redhat.com
> > > 46. [166]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 47. mailto:[167]tejaswinipoluri3@gmail.com
> > > 48. mailto:[168]bmarzins@redhat.com
> > > 49. mailto:[169]tejaswinipoluri3@gmail.com
> > > 50. mailto:[170]bmarzins@redhat.com
> > > 51. mailto:[171]dm-devel@redhat.com
> > > 52. [172]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 53. mailto:[173]dm-devel@redhat.com
> > > 54. [174]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 55. mailto:[175]tejaswinipoluri3@gmail.com
> > > 56. mailto:[176]bmarzins@redhat.com
> > > 57. mailto:[177]dm-devel@redhat.com
> > > 58. [178]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 59. mailto:[179]dm-devel@redhat.com
> > > 60. [180]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 61. mailto:[181]bmarzins@redhat.com
> > > 62. mailto:[182]bmarzins@redhat.com
> > > 63. mailto:[183]tejaswinipoluri3@gmail.com
> > > 64. mailto:[184]bmarzins@redhat.com
> > > 65. mailto:[185]tejaswinipoluri3@gmail.com
> > > 66. mailto:[186]bmarzins@redhat.com
> > > 67. mailto:[187]dm-devel@redhat.com
> > > 68. [188]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 69. mailto:[189]dm-devel@redhat.com
> > > 70. [190]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 71. mailto:[191]tejaswinipoluri3@gmail.com
> > > 72. mailto:[192]bmarzins@redhat.com
> > > 73. mailto:[193]dm-devel@redhat.com
> > > 74. [194]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 75. mailto:[195]dm-devel@redhat.com
> > > 76. [196]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 77. mailto:[197]tejaswinipoluri3@gmail.com
> > > 78. mailto:[198]bmarzins@redhat.com
> > > 79. mailto:[199]tejaswinipoluri3@gmail.com
> > > 80. mailto:[200]bmarzins@redhat.com
> > > 81. mailto:[201]dm-devel@redhat.com
> > > 82. [202]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 83. mailto:[203]dm-devel@redhat.com
> > > 84. [204]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 85. mailto:[205]tejaswinipoluri3@gmail.com
> > > 86. mailto:[206]bmarzins@redhat.com
> > > 87. mailto:[207]dm-devel@redhat.com
> > > 88. [208]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 89. mailto:[209]dm-devel@redhat.com
> > > 90. [210]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 91. mailto:[211]bmarzins@redhat.com
> > > 92. mailto:[212]tejaswinipoluri3@gmail.com
> > > 93. mailto:[213]bmarzins@redhat.com
> > > 94. mailto:[214]tejaswinipoluri3@gmail.com
> > > 95. mailto:[215]bmarzins@redhat.com
> > > 96. mailto:[216]dm-devel@redhat.com
> > > 97. [217]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 98. mailto:[218]dm-devel@redhat.com
> > > 99. [219]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 100. mailto:[220]tejaswinipoluri3@gmail.com
> > > 101. mailto:[221]bmarzins@redhat.com
> > > 102. mailto:[222]dm-devel@redhat.com
> > > 103. [223]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 104. mailto:[224]dm-devel@redhat.com
> > > 105. [225]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 106. mailto:[226]tejaswinipoluri3@gmail.com
> > > 107. mailto:[227]bmarzins@redhat.com
> > > 108. mailto:[228]tejaswinipoluri3@gmail.com
> > > 109. mailto:[229]bmarzins@redhat.com
> > > 110. mailto:[230]dm-devel@redhat.com
> > > 111. [231]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 112. mailto:[232]dm-devel@redhat.com
> > > 113. [233]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 114. mailto:[234]tejaswinipoluri3@gmail.com
> > > 115. mailto:[235]bmarzins@redhat.com
> > > 116. mailto:[236]dm-devel@redhat.com
> > > 117. [237]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 118. mailto:[238]dm-devel@redhat.com
> > > 119. [239]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:bmarzins@redhat.com
> > 2. mailto:bmarzins@redhat.com
> > 3. mailto:bmarzins@redhat.com
> > 4. mailto:bmarzins@redhat.com
> > 5. mailto:tejaswinipoluri3@gmail.com
> > 6. mailto:bmarzins@redhat.com
> > 7. mailto:tejaswinipoluri3@gmail.com
> > 8. mailto:bmarzins@redhat.com
> > 9. mailto:dm-devel@redhat.com
> > 10. https://www.redhat.com/mailman/listinfo/dm-devel
> > 11. mailto:dm-devel@redhat.com
> > 12. https://www.redhat.com/mailman/listinfo/dm-devel
> > 13. mailto:tejaswinipoluri3@gmail.com
> > 14. mailto:bmarzins@redhat.com
> > 15. mailto:dm-devel@redhat.com
> > 16. https://www.redhat.com/mailman/listinfo/dm-devel
> > 17. mailto:dm-devel@redhat.com
> > 18. https://www.redhat.com/mailman/listinfo/dm-devel
> > 19. mailto:tejaswinipoluri3@gmail.com
> > 20. mailto:bmarzins@redhat.com
> > 21. mailto:tejaswinipoluri3@gmail.com
> > 22. mailto:bmarzins@redhat.com
> > 23. mailto:dm-devel@redhat.com
> > 24. https://www.redhat.com/mailman/listinfo/dm-devel
> > 25. mailto:dm-devel@redhat.com
> > 26. https://www.redhat.com/mailman/listinfo/dm-devel
> > 27. mailto:tejaswinipoluri3@gmail.com
> > 28. mailto:bmarzins@redhat.com
> > 29. mailto:dm-devel@redhat.com
> > 30. https://www.redhat.com/mailman/listinfo/dm-devel
> > 31. mailto:dm-devel@redhat.com
> > 32. https://www.redhat.com/mailman/listinfo/dm-devel
> > 33. mailto:bmarzins@redhat.com
> > 34. mailto:tejaswinipoluri3@gmail.com
> > 35. mailto:bmarzins@redhat.com
> > 36. mailto:tejaswinipoluri3@gmail.com
> > 37. mailto:bmarzins@redhat.com
> > 38. mailto:dm-devel@redhat.com
> > 39. https://www.redhat.com/mailman/listinfo/dm-devel
> > 40. mailto:dm-devel@redhat.com
> > 41. https://www.redhat.com/mailman/listinfo/dm-devel
> > 42. mailto:tejaswinipoluri3@gmail.com
> > 43. mailto:bmarzins@redhat.com
> > 44. mailto:dm-devel@redhat.com
> > 45. https://www.redhat.com/mailman/listinfo/dm-devel
> > 46. mailto:dm-devel@redhat.com
> > 47. https://www.redhat.com/mailman/listinfo/dm-devel
> > 48. mailto:tejaswinipoluri3@gmail.com
> > 49. mailto:bmarzins@redhat.com
> > 50. mailto:tejaswinipoluri3@gmail.com
> > 51. mailto:bmarzins@redhat.com
> > 52. mailto:dm-devel@redhat.com
> > 53. https://www.redhat.com/mailman/listinfo/dm-devel
> > 54. mailto:dm-devel@redhat.com
> > 55. https://www.redhat.com/mailman/listinfo/dm-devel
> > 56. mailto:tejaswinipoluri3@gmail.com
> > 57. mailto:bmarzins@redhat.com
> > 58. mailto:dm-devel@redhat.com
> > 59. https://www.redhat.com/mailman/listinfo/dm-devel
> > 60. mailto:dm-devel@redhat.com
> > 61. https://www.redhat.com/mailman/listinfo/dm-devel
> > 62. mailto:bmarzins@redhat.com
> > 63. mailto:bmarzins@redhat.com
> > 64. mailto:tejaswinipoluri3@gmail.com
> > 65. mailto:bmarzins@redhat.com
> > 66. mailto:tejaswinipoluri3@gmail.com
> > 67. mailto:bmarzins@redhat.com
> > 68. mailto:dm-devel@redhat.com
> > 69. https://www.redhat.com/mailman/listinfo/dm-devel
> > 70. mailto:dm-devel@redhat.com
> > 71. https://www.redhat.com/mailman/listinfo/dm-devel
> > 72. mailto:tejaswinipoluri3@gmail.com
> > 73. mailto:bmarzins@redhat.com
> > 74. mailto:dm-devel@redhat.com
> > 75. https://www.redhat.com/mailman/listinfo/dm-devel
> > 76. mailto:dm-devel@redhat.com
> > 77. https://www.redhat.com/mailman/listinfo/dm-devel
> > 78. mailto:tejaswinipoluri3@gmail.com
> > 79. mailto:bmarzins@redhat.com
> > 80. mailto:tejaswinipoluri3@gmail.com
> > 81. mailto:bmarzins@redhat.com
> > 82. mailto:dm-devel@redhat.com
> > 83. https://www.redhat.com/mailman/listinfo/dm-devel
> > 84. mailto:dm-devel@redhat.com
> > 85. https://www.redhat.com/mailman/listinfo/dm-devel
> > 86. mailto:tejaswinipoluri3@gmail.com
> > 87. mailto:bmarzins@redhat.com
> > 88. mailto:dm-devel@redhat.com
> > 89. https://www.redhat.com/mailman/listinfo/dm-devel
> > 90. mailto:dm-devel@redhat.com
> > 91. https://www.redhat.com/mailman/listinfo/dm-devel
> > 92. mailto:bmarzins@redhat.com
> > 93. mailto:tejaswinipoluri3@gmail.com
> > 94. mailto:bmarzins@redhat.com
> > 95. mailto:tejaswinipoluri3@gmail.com
> > 96. mailto:bmarzins@redhat.com
> > 97. mailto:dm-devel@redhat.com
> > 98. https://www.redhat.com/mailman/listinfo/dm-devel
> > 99. mailto:dm-devel@redhat.com
> > 100. https://www.redhat.com/mailman/listinfo/dm-devel
> > 101. mailto:tejaswinipoluri3@gmail.com
> > 102. mailto:bmarzins@redhat.com
> > 103. mailto:dm-devel@redhat.com
> > 104. https://www.redhat.com/mailman/listinfo/dm-devel
> > 105. mailto:dm-devel@redhat.com
> > 106. https://www.redhat.com/mailman/listinfo/dm-devel
> > 107. mailto:tejaswinipoluri3@gmail.com
> > 108. mailto:bmarzins@redhat.com
> > 109. mailto:tejaswinipoluri3@gmail.com
> > 110. mailto:bmarzins@redhat.com
> > 111. mailto:dm-devel@redhat.com
> > 112. https://www.redhat.com/mailman/listinfo/dm-devel
> > 113. mailto:dm-devel@redhat.com
> > 114. https://www.redhat.com/mailman/listinfo/dm-devel
> > 115. mailto:tejaswinipoluri3@gmail.com
> > 116. mailto:bmarzins@redhat.com
> > 117. mailto:dm-devel@redhat.com
> > 118. https://www.redhat.com/mailman/listinfo/dm-devel
> > 119. mailto:dm-devel@redhat.com
> > 120. https://www.redhat.com/mailman/listinfo/dm-devel
> > 121. mailto:bmarzins@redhat.com
> > 122. mailto:bmarzins@redhat.com
> > 123. mailto:bmarzins@redhat.com
> > 124. mailto:tejaswinipoluri3@gmail.com
> > 125. mailto:bmarzins@redhat.com
> > 126. mailto:tejaswinipoluri3@gmail.com
> > 127. mailto:bmarzins@redhat.com
> > 128. mailto:dm-devel@redhat.com
> > 129. https://www.redhat.com/mailman/listinfo/dm-devel
> > 130. mailto:dm-devel@redhat.com
> > 131. https://www.redhat.com/mailman/listinfo/dm-devel
> > 132. mailto:tejaswinipoluri3@gmail.com
> > 133. mailto:bmarzins@redhat.com
> > 134. mailto:dm-devel@redhat.com
> > 135. https://www.redhat.com/mailman/listinfo/dm-devel
> > 136. mailto:dm-devel@redhat.com
> > 137. https://www.redhat.com/mailman/listinfo/dm-devel
> > 138. mailto:tejaswinipoluri3@gmail.com
> > 139. mailto:bmarzins@redhat.com
> > 140. mailto:tejaswinipoluri3@gmail.com
> > 141. mailto:bmarzins@redhat.com
> > 142. mailto:dm-devel@redhat.com
> > 143. https://www.redhat.com/mailman/listinfo/dm-devel
> > 144. mailto:dm-devel@redhat.com
> > 145. https://www.redhat.com/mailman/listinfo/dm-devel
> > 146. mailto:tejaswinipoluri3@gmail.com
> > 147. mailto:bmarzins@redhat.com
> > 148. mailto:dm-devel@redhat.com
> > 149. https://www.redhat.com/mailman/listinfo/dm-devel
> > 150. mailto:dm-devel@redhat.com
> > 151. https://www.redhat.com/mailman/listinfo/dm-devel
> > 152. mailto:bmarzins@redhat.com
> > 153. mailto:tejaswinipoluri3@gmail.com
> > 154. mailto:bmarzins@redhat.com
> > 155. mailto:tejaswinipoluri3@gmail.com
> > 156. mailto:bmarzins@redhat.com
> > 157. mailto:dm-devel@redhat.com
> > 158. https://www.redhat.com/mailman/listinfo/dm-devel
> > 159. mailto:dm-devel@redhat.com
> > 160. https://www.redhat.com/mailman/listinfo/dm-devel
> > 161. mailto:tejaswinipoluri3@gmail.com
> > 162. mailto:bmarzins@redhat.com
> > 163. mailto:dm-devel@redhat.com
> > 164. https://www.redhat.com/mailman/listinfo/dm-devel
> > 165. mailto:dm-devel@redhat.com
> > 166. https://www.redhat.com/mailman/listinfo/dm-devel
> > 167. mailto:tejaswinipoluri3@gmail.com
> > 168. mailto:bmarzins@redhat.com
> > 169. mailto:tejaswinipoluri3@gmail.com
> > 170. mailto:bmarzins@redhat.com
> > 171. mailto:dm-devel@redhat.com
> > 172. https://www.redhat.com/mailman/listinfo/dm-devel
> > 173. mailto:dm-devel@redhat.com
> > 174. https://www.redhat.com/mailman/listinfo/dm-devel
> > 175. mailto:tejaswinipoluri3@gmail.com
> > 176. mailto:bmarzins@redhat.com
> > 177. mailto:dm-devel@redhat.com
> > 178. https://www.redhat.com/mailman/listinfo/dm-devel
> > 179. mailto:dm-devel@redhat.com
> > 180. https://www.redhat.com/mailman/listinfo/dm-devel
> > 181. mailto:bmarzins@redhat.com
> > 182. mailto:bmarzins@redhat.com
> > 183. mailto:tejaswinipoluri3@gmail.com
> > 184. mailto:bmarzins@redhat.com
> > 185. mailto:tejaswinipoluri3@gmail.com
> > 186. mailto:bmarzins@redhat.com
> > 187. mailto:dm-devel@redhat.com
> > 188. https://www.redhat.com/mailman/listinfo/dm-devel
> > 189. mailto:dm-devel@redhat.com
> > 190. https://www.redhat.com/mailman/listinfo/dm-devel
> > 191. mailto:tejaswinipoluri3@gmail.com
> > 192. mailto:bmarzins@redhat.com
> > 193. mailto:dm-devel@redhat.com
> > 194. https://www.redhat.com/mailman/listinfo/dm-devel
> > 195. mailto:dm-devel@redhat.com
> > 196. https://www.redhat.com/mailman/listinfo/dm-devel
> > 197. mailto:tejaswinipoluri3@gmail.com
> > 198. mailto:bmarzins@redhat.com
> > 199. mailto:tejaswinipoluri3@gmail.com
> > 200. mailto:bmarzins@redhat.com
> > 201. mailto:dm-devel@redhat.com
> > 202. https://www.redhat.com/mailman/listinfo/dm-devel
> > 203. mailto:dm-devel@redhat.com
> > 204. https://www.redhat.com/mailman/listinfo/dm-devel
> > 205. mailto:tejaswinipoluri3@gmail.com
> > 206. mailto:bmarzins@redhat.com
> > 207. mailto:dm-devel@redhat.com
> > 208. https://www.redhat.com/mailman/listinfo/dm-devel
> > 209. mailto:dm-devel@redhat.com
> > 210. https://www.redhat.com/mailman/listinfo/dm-devel
> > 211. mailto:bmarzins@redhat.com
> > 212. mailto:tejaswinipoluri3@gmail.com
> > 213. mailto:bmarzins@redhat.com
> > 214. mailto:tejaswinipoluri3@gmail.com
> > 215. mailto:bmarzins@redhat.com
> > 216. mailto:dm-devel@redhat.com
> > 217. https://www.redhat.com/mailman/listinfo/dm-devel
> > 218. mailto:dm-devel@redhat.com
> > 219. https://www.redhat.com/mailman/listinfo/dm-devel
> > 220. mailto:tejaswinipoluri3@gmail.com
> > 221. mailto:bmarzins@redhat.com
> > 222. mailto:dm-devel@redhat.com
> > 223. https://www.redhat.com/mailman/listinfo/dm-devel
> > 224. mailto:dm-devel@redhat.com
> > 225. https://www.redhat.com/mailman/listinfo/dm-devel
> > 226. mailto:tejaswinipoluri3@gmail.com
> > 227. mailto:bmarzins@redhat.com
> > 228. mailto:tejaswinipoluri3@gmail.com
> > 229. mailto:bmarzins@redhat.com
> > 230. mailto:dm-devel@redhat.com
> > 231. https://www.redhat.com/mailman/listinfo/dm-devel
> > 232. mailto:dm-devel@redhat.com
> > 233. https://www.redhat.com/mailman/listinfo/dm-devel
> > 234. mailto:tejaswinipoluri3@gmail.com
> > 235. mailto:bmarzins@redhat.com
> > 236. mailto:dm-devel@redhat.com
> > 237. https://www.redhat.com/mailman/listinfo/dm-devel
> > 238. mailto:dm-devel@redhat.com
> > 239. https://www.redhat.com/mailman/listinfo/dm-devel
>
> > commit 79ab9090d3fbcdb5844478419135d1390cf548c2
> > Author: Tejaswini <tejaswinipoluri3@gmail.com>
> > Date: Wed Jul 8 15:08:56 2015 +0530
> >
> > multipathd: Fixing add map functionality
> >
> > Add map feature of multipathd tools fails as the device
> > is also been completely removed along with removing the map
> > in the remove map code. So when add map is called we are
> > creating the device again in kernel and doing add map
> > using the coloasce_paths code.
> >
> > Signed-off-by: Tejaswini Poluri <tpoluri@mvista.com>
> >
> > diff --git a/multipathd/cli_handlers.c b/multipathd/cli_handlers.c
> > index dc96c45..c54c767 100644
> > --- a/multipathd/cli_handlers.c
> > +++ b/multipathd/cli_handlers.c
> > @@ -537,7 +537,7 @@ cli_add_map (void * v, char ** reply, int * len,
> void * data)
> > char dev_path[PATH_SIZE];
> > char *alias;
> > int rc;
> > -
> > + char *refwwid;
> > param = convert_dev(param, 0);
> > condlog(2, "%s: add map (operator)", param);
> >
> > @@ -547,6 +547,14 @@ cli_add_map (void * v, char ** reply, int * len,
> void * data)
> > condlog(2, "%s: map blacklisted", param);
> > return 0;
> > }
> > + rc = get_refwwid(param, DEV_DEVMAP, vecs->pathvec, &refwwid);
> > +
> > + if (refwwid) {
> > + condlog(2, "%s: add map (operator)", refwwid);
> > + if(coalesce_paths(vecs, NULL, refwwid, 0))
> > + condlog(2, "%s: coalesce-paths failed", param);
> > + dm_lib_release();
> > + }
> > minor = dm_get_minor(param);
> > if (minor < 0) {
> > condlog(2, "%s: not a device mapper table", param);
> > @@ -566,6 +574,7 @@ cli_add_map (void * v, char ** reply, int * len,
> void * data)
> > }
> > rc = ev_add_map(dev_path, alias, vecs);
> > FREE(alias);
> > + FREE(refwwid);
> > return rc;
> > }
> >
>
> > commit 910b4a82ec483b48eaf8b24eb3d7829273c690ed
> > Author: Tejaswini <tejaswinipoluri3@gmail.com>
> > Date: Wed Jul 8 17:18:03 2015 +0530
> >
> > multipathd: Disabled code that is not being used.
> >
> > This part of the code is moved to cli_add_map and
> > disabled here as it is not used by any function call
> > here.
> >
> > Signed-off-by: Tejaswini <tejaswinipoluri3@gmail.com>
> >
> > diff --git a/multipathd/main.c b/multipathd/main.c
> > index f876258..060237c 100644
> > --- a/multipathd/main.c
> > +++ b/multipathd/main.c
> > @@ -329,6 +329,8 @@ ev_add_map (char * dev, char * alias, struct vectors
> * vecs)
> > return 1;
> > }
> > }
> > +#if 0 /*Disabled as the code is not being used by anyone.
> > + TODO:confirm that no feature requires this code*/
> > r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec, &refwwid);
> >
> > if (refwwid) {
> > @@ -344,6 +346,7 @@ ev_add_map (char * dev, char * alias, struct vectors
> * vecs)
> > condlog(0, "%s: uev_add_map %s failed", alias, dev);
> >
> > FREE(refwwid);
> > +#endif
> > return r;
> > }
> >
>
>
[-- Attachment #1.2: Type: text/html, Size: 123107 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-07-16 10:37 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-18 8:39 reinstate path not working Tejaswini Poluri
2015-05-18 16:27 ` Benjamin Marzinski
[not found] ` <CAH=b03t3QGuHM_x-eQTGZRkpYsAmOT4yMRCPQhp-smWM6ZXRhw@mail.gmail.com>
[not found] ` <CAH=b03v=haA-5A=Vj1EhDVnhDePAZ5u=UaWdhW7zQxGcS8hV2Q@mail.gmail.com>
[not found] ` <20150605220649.GD2754@octiron.msp.redhat.com>
[not found] ` <CAH=b03vRNbV0oFze-s__SMb8cDJh5VYQ3uS9OpMhHoRxZhBN=w@mail.gmail.com>
[not found] ` <CAH=b03tj_EZvAh5v1OG3jhubyhQnkaN=gJsGVsjrjJMQm990zQ@mail.gmail.com>
[not found] ` <20150611205149.GA1409@octiron.msp.redhat.com>
2015-06-23 10:18 ` Tejaswini Poluri
2015-06-25 23:02 ` Benjamin Marzinski
2015-06-26 6:51 ` Tejaswini Poluri
2015-06-29 19:20 ` Benjamin Marzinski
2015-06-30 5:52 ` Tejaswini Poluri
2015-07-06 17:45 ` Benjamin Marzinski
2015-07-08 12:01 ` Tejaswini Poluri
2015-07-10 16:06 ` Benjamin Marzinski
2015-07-16 10:37 ` Tejaswini Poluri
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.