<div dir="ltr"><div>Hi Ben, <br><br></div><div>This is regarding the add map issue I have been discussing. Posting the issue again to remind.<br><br><b>Case 1 : remove and add map.</b><br>root@x86-generic-64:~# multipathd -k'show maps'<br>name sysfs uuid<br>dmpath0 dm-0 1IET_00010001<br>root@x86-generic-64:~# multipathd -k'remove map dmpath0'<br>ok<br>root@x86-generic-64:~# multipathd -k'show maps'<br>root@x86-generic-64:~# multipathd -k'add map dmpath0'<br>ok<br>root@x86-generic-64:~# multipathd -k'show maps'<br>root@x86-generic-64:~#<br>Once a map is removed, we are able to add it only using #multipath command and not using multipathd tools. <br><br>I have fixed the problem with two approaches. I would like you to review the same.<br></div><div><b>Patch1</b> : 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.<br><br></div><div><b>Patch 2</b>: 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.<br><br>r = get_refwwid(dev, DEV_DEVMAP, vecs->pathvec,&refwwid);<br><br> if (refwwid) {<br> r = coalesce_paths(vecs, NULL, refwwid,0);<br> dm_lib_release();<br> }<br><br></div><div>changed dev to param.<br><br></div><div>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.<br></div><div><br></div><div>I guess Patch2 is the way u have suggested me in the previous mail. Please review it and share your views.<br></div><div><br></div><div>Regards,<br></div><div>Tejaswini<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski <span dir="ltr"><<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Wed, Jun 10, 2015 at 11:46:51AM +0530, Tejaswini Poluri wrote:<br>
> <br>
> > We are testing multipathd tools with all the possible options and the<br>
> > following fails.<br>
> ><br>
> > Case 1 : remove and add map.<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > name sysfs uuid<br>
> > dmpath0 dm-0 1IET_00010001<br>
> > root@x86-generic-64:~# multipathd -k'remove map dmpath0'<br>
> > ok<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > root@x86-generic-64:~# multipathd -k'add map dmpath0'<br>
> > ok<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > root@x86-generic-64:~#<br>
> > Once a map is removed, we are able to add it only using #multipath <br>
> > command and not using multipathd tools.<br>
><br>
> It is working the way it was designed, but possibly it would make sense<br>
> to change the design.<br>
><br>
> You have mentioned that it would make sense to change the design to add<br>
> map. Are there plans to change the design ?<br>
> I am trying to understand the code flow to change the design. Can you<br>
> guide me if we should stop removing the device from in the remove map code<br>
> flow or start adding the device and the map in the add map code flow.<br>
><br>
> have tried to understand the remove map code flow of multipathd in 0.4.8<br>
> code.<br>
<br>
</div></div>I think that we want multipath to actually remove the map (instead of<br>
just not monitoring it) when you call "remove map <map>". We just want<br>
"add map <map>" to try to create the map if it doesn't exist. To do<br>
that, you would need to first firgure out what WWID is associated with<br>
<map>. Presumably, <map> could either be an alias, wwid, or even the<br>
name of a path in the map. Once you found the map, you would have to<br>
call the code to create the map.<br>
<br>
Also, to answer your IRC question, no the 0.4.8 code is not still being<br>
developed upstream. All upstream patches only go against the current<br>
head. There are no other upstream branches.<br>
<br>
-Ben<br>
<span>><br>
> ev_remove_map (char * devname, struct vectors * vecs)<br>
><br>
> flush_map(mpp, vecs);<br>
><br>
> dm_flush_map(mpp->alias, DEFAULT_TARGET);<br>
><br>
> if (!dm_map_present(mapname))<br>
><br>
> return 0;<br>
><br>
> if (dm_type(mapname, type) <= 0)<br>
><br>
> return 1;<br>
><br>
> if (dm_remove_partmaps(mapname))<br>
><br>
> return 1;<br>
><br>
> if (dm_get_opencount(mapname)) {<br>
><br>
> condlog(2, "%s: map in use", mapname);<br>
><br>
> return 1;<br>
><br>
> } <br>
><br>
> r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);<br>
><br>
> if (r) {<br>
><br>
> condlog(4, "multipath map %s removed", mapname);<br>
><br>
> return 0;<br>
><br>
> }<br>
><br>
> <br>
><br>
> orphan_paths(vecs->pathvec, mpp);<br>
><br>
> remove_map(mpp, vecs, stop_waiter_thread, 1);<br>
><br>
> Is removing this below line, the right step to stop removing the device ?<br>
> r = dm_simplecmd(DM_DEVICE_REMOVE, mapname);<br>
><br>
> Regards,<br>
><br>
> Tejaswini<br>
><br>
> On Mon, Jun 8, 2015 at 11:15 AM, Tejaswini Poluri<br>
</span><span>> <[1]<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a>> wrote:<br>
><br>
> Thanks a lot Ben for the quick and detailed reply. I have been<br>
> struggling to understand and conclude the issues with multipath as I am<br>
> the only one working from my team. Your inputs help me a lot. Thanks<br>
> again.<br>
> Regards,<br>
> Tejaswini<br>
> On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski<br>
</span><div><div>> <[2]<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a>> wrote:<br>
><br>
> On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini Poluri wrote:<br>
> > Hii Ben,<br>
> ><br>
> > We are testing multipathd tools with all the possible options and<br>
> the<br>
> > following fails.<br>
> ><br>
> > Case 1 : remove and add map.<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > name sysfs uuid<br>
> > dmpath0 dm-0 1IET_00010001<br>
> > root@x86-generic-64:~# multipathd -k'remove map dmpath0'<br>
> > ok<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > root@x86-generic-64:~# multipathd -k'add map dmpath0'<br>
> > ok<br>
> > root@x86-generic-64:~# multipathd -k'show maps'<br>
> > root@x86-generic-64:~#<br>
> > Once a map is removed, we are able to add it only using<br>
> #multipath <br>
> > command and not using multipathd tools.<br>
><br>
> It is working the way it was designed, but possibly it would make<br>
> sense<br>
> to change the design. The "remove map" command, not only stops<br>
> multipathd from monitoring the multipath device, but it removes it<br>
> from<br>
> the system as well. The "add map" command makes multipath monitor an<br>
> already existing multipath device that in wasn't previously<br>
> monitoring.<br>
> These commands do this for historical reasons. multipathd wasn't<br>
> originally in charge of creating multipath devices, multipath was. <br>
> Once<br>
> it had created the device, it ran<br>
><br>
> multipathd -k"add map <MAP>"<br>
><br>
> to make multipathd start monitoring it. However things haven't worked<br>
> this way since RHEL4, so possibly "add map" should actually create the<br>
> device if it doesn't currently exist.<br>
> > Case 2 : Active paths test case<br>
> > # while true ; do sleep 3 ; multipathd -k'remove path sdb' ;<br>
> multipathd<br>
> > -k'add path sdb' ; multipathd -k'show maps status' ; done<br>
> > ok<br>
> > ok<br>
> > name failback queueing paths dm-st<br>
> > dmpath0 - - 1 active // It should be 2.<br>
><br>
> This is simply a timing issue. What you are seeing it the number of<br>
> active paths. These are paths that the kernel can use. The "add path"<br>
> command doesn't update the kernel state. This happens later in<br>
> response<br>
> to the kernel reloading the device table. So, in a second or two, this<br>
> will say 2, as expected.<br>
><br>
> > We would like to know if the test cases are valid and if these<br>
> are bugs or<br>
> > any design issues.<br>
> ><br>
> > Case 3 : Fail path and reinstate path<br>
> > root@x86-generic-64:~# multipathd -k"fail path sdc"; multipathd<br>
> > -k'reinstate path sdc'; multipathd -k"show paths";<br>
> > > [ 3962.708523] device-mapper: multipath: Failing path 8:32.<br>
> > > ok<br>
> > > ok<br>
> > > hcil dev dev_t pri dm_st chk_st next_check<br>
> > > 4:0:0:1 sdc 8:32 1 [active][faulty] .......... 1/20 <br>
> <==CHECK<br>
> > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........ 4/20<br>
> > sdc path becomes [active][ready] only after the polling interval<br>
> but not<br>
> > immediately after the reinstate path command.<br>
> > You have answered that this is a design issue. But we have heard<br>
> from our<br>
> > test team that the same test case works in RHEL6. Did you observe<br>
> it?<br>
> > I am also finding that the test cases fail because we are trying<br>
> to do<br>
> > multiple commands at one shot. Please share your thoughts so<br>
> that it<br>
> > could help me in debugging the issues further.<br>
> ><br>
><br>
> It's totally possible that the checker state is immediately updated in<br>
> RHEL6. Like I said before, what it currently does, although correct,<br>
> is confusing, and perhaps we need a different checker state for paths<br>
> where the "fail path" command has been used.<br>
><br>
> -Ben<br>
> > Regards,<br>
> > Tejaswini<br>
> > On Tue, May 19, 2015 at 5:37 PM, Tejaswini Poluri<br>
</div></div><span>> > <[1][3]<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a>> wrote:<br>
> ><br>
> > Thanks a lot Ben. I will look into it more. <br>
> > On Mon, May 18, 2015 at 9:57 PM, Benjamin Marzinski<br>
</span><div><div>> > <[2][4]<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a>> wrote:<br>
> ><br>
> > On Mon, May 18, 2015 at 02:09:27PM +0530, Tejaswini Poluri<br>
> wrote:<br>
> > > Hii,<br>
> > > We are trying to test multipath setup in our target and<br>
> tried the<br>
> > various<br>
> > > commands of multipathd demaon and we find the following<br>
> error:<br>
> > > root@x86-generic-64:~# multipathd -k"fail path sdc";<br>
> multipathd<br>
> > > -k'reinstate path<br>
> > > sdc'; multipathd -k"show paths";<br>
> > > [ 3962.708523] device-mapper: multipath: Failing<br>
> path 8:32.<br>
> > > ok<br>
> > > ok<br>
> > > hcil dev dev_t pri dm_st chk_st next_check<br>
> > > 4:0:0:1 sdc 8:32 1 [active][faulty] .......... 1/20 <br>
> <<<===<br>
> > CHECK<br>
> > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........ 4/20<br>
> > > sdc path becomes [active][ready] only after the polling<br>
> interval<br>
> > but not<br>
> > > immediately after the reinstate path command. <br>
> > > I am observing this in latest multipath tools in ubuntu<br>
> machine<br>
> > as well.<br>
> > > Please let me know if its a known issue or if I am doing<br>
> > something wrong.<br>
> > > Regards.<br>
> > > Tejaswini<br>
> ><br>
> > the reinstate command is supposed to reinstate the device<br>
> with the<br>
> > kernel, and it does that. The checker state doesn't change<br>
> until the<br>
> > next time that the path is checked. I agree that it's odd<br>
> that the<br>
> > check state switches to faulty as soon as you fail the path,<br>
> but it<br>
> > doesn't switch back until the next check after you reinistate<br>
> it.<br>
> ><br>
> > The issue is that multipathd needs to override the checker<br>
> output,<br>
> > so that a failed path won't be immeditately reinstated. Once<br>
> the<br>
> > path comes back, multipathd wants to record the switch in the<br>
> checker<br>
> > thread, so that it can refresh path information what wasn't<br>
> > automatically done when the path was reinstated. However, it<br>
> may make<br>
> > more sense to have a different checker state for when the<br>
> device is<br>
> > in the failed state, so that it's obvious that the checker<br>
> state is<br>
> > being overruled.<br>
> ><br>
> > -Ben<br>
> ><br>
> > > --<br>
> > > dm-devel mailing list<br>
</div></div>> > > [3][5]<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> > > [4][6]<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> ><br>
> > --<br>
> > dm-devel mailing list<br>
> > [5][7]<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> > [6][8]<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> ><br>
> > References<br>
> ><br>
> > Visible links<br>
> > 1. mailto:[9]<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a><br>
> > 2. mailto:[10]<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a><br>
> > 3. mailto:[11]<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> > 4. [12]<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> > 5. mailto:[13]<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> > 6. [14]<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
<span>><br>
> References<br>
><br>
> Visible links<br>
> 1. mailto:<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a><br>
> 2. mailto:<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a><br>
</span>> 3. mailto:<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a><br>
> 4. mailto:<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a><br>
<span>> 5. mailto:<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> 6. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
</span>> 7. mailto:<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> 8. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 9. mailto:<a href="mailto:tejaswinipoluri3@gmail.com" target="_blank">tejaswinipoluri3@gmail.com</a><br>
> 10. mailto:<a href="mailto:bmarzins@redhat.com" target="_blank">bmarzins@redhat.com</a><br>
> 11. mailto:<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> 12. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 13. mailto:<a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> 14. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
</blockquote></div><br></div></div>