<div dir="ltr"><div>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.<br><br>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 <br>1.dm_map_present, <br>2.add_map_without_path<br></div><div>3. sync_map_state<br></div><div>which are responsible for registering the map and displaying it.<br><br></div><div>So, I think moving the below code from ev_add_map to cli_add_map should be a good idea right.<br><br><span class="im">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>
> }</span><br></div><div><br></div><div>What do u think?<br><br><br></div><div>Regards,<br></div><div>Tejaswini<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 4:32 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 class="HOEnZb"><div class="h5">On Tue, Jun 23, 2015 at 03:48:26PM +0530, Tejaswini Poluri wrote:<br>
> Hi Ben,<br>
><br>
> This is regarding the add map issue I have been discussing. Posting the<br>
> issue again to remind.<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>
> I have fixed the problem with two approaches. I would like you to review<br>
> the same.<br>
> Patch1 : By making 'remove map dmpath0' to remove only the map and not the<br>
> device. I have added extra functions discard_map and dm_remove_map so as<br>
> to not interfere with the existing code.<br>
><br>
> Patch 2: The approach you have suggested.By getting wwid from the mapname<br>
> and doing coalesce_paths. I have just moved the following code in<br>
> ev_add_map to cli_add_map.<br>
<br>
</div></div>This is the general idea we'd like to go with. However, looking at the<br>
latest upstream code, I don't think you should pull code in from<br>
ev_add_map() to cli_add_map() like your patch does. cli_add_map()<br>
already calls ev_add_map(), and ev_add_map() is certainly able to add<br>
the map if it doesn't already exist.<br>
<br>
You would just need to call it with<br>
<br>
ev_add_map(param, NULL, vecs);<br>
<br>
and ev_add_map() will happily create you a new multipath device. All<br>
you need to do is make sure that all the functions that ev_add_map()<br>
calls with alias can accept a NULL value there.<br>
<br>
This might not be the best way to go about this, however. It turns out<br>
that right now, even though ev_add_map() technically has the ability to<br>
create new maps, nothing currently uses it, and it really doesn't make<br>
sense for it to be there. Instead of just copying that code, you could<br>
pull the map creation code out of ev_add_map() and add it to<br>
cli_add_map(), for those situations where the requested device doesn't<br>
already exist.<br>
<br>
But having the code in both cli_add_map() and ev_add_map() when one<br>
already calls the other doesn't seem necessary.<br>
<br>
-Ben<br>
<span class=""><br>
<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>
> changed dev to param.<br>
><br>
> I have tested the same in all 3 versions -0.4.8, 0.4.9 and 0.5.0. It would<br>
> be great if you can review the same so that it doesn't cause any extra<br>
> side effects.<br>
> I guess Patch2 is the way u have suggested me in the previous mail. Please<br>
> review it and share your views.<br>
> Regards,<br>
> Tejaswini<br>
> On Fri, Jun 12, 2015 at 2:21 AM, Benjamin Marzinski<br>
</span><div><div class="h5">> <[1]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a>> wrote:<br>
><br>
> 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<br>
> 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<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.<br>
> ><br>
> > You have mentioned that it would make sense to change the design to<br>
> add<br>
> > map. Are there plans to change the design ?<br>
> > I am trying to understand the code flow to change the design. Can<br>
> you<br>
> > guide me if we should stop removing the device from in the remove<br>
> map code<br>
> > flow or start adding the device and the map in the add map code<br>
> flow.<br>
> ><br>
> > have tried to understand the remove map code flow of multipathd in<br>
> 0.4.8<br>
> > code.<br>
><br>
> 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>
> ><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,<br>
> 1);<br>
> ><br>
> > Is removing this below line, the right step to stop removing the<br>
> 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>
</div></div><span class="">> > <[1][2]<a href="mailto:tejaswinipoluri3@gmail.com">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<br>
> as I am<br>
> > the only one working from my team. Your inputs help me a lot.<br>
> Thanks<br>
> > again.<br>
> > Regards,<br>
> > Tejaswini<br>
> > On Sat, Jun 6, 2015 at 3:36 AM, Benjamin Marzinski<br>
</span><div><div class="h5">> > <[2][3]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a>> wrote:<br>
> ><br>
> > On Fri, Jun 05, 2015 at 02:31:20PM +0530, Tejaswini Poluri<br>
> wrote:<br>
> > > Hii Ben,<br>
> > ><br>
> > > We are testing multipathd tools with all the possible<br>
> 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<br>
> 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<br>
> it<br>
> > from<br>
> > the system as well. The "add map" command makes multipath<br>
> monitor an<br>
> > already existing multipath device that in wasn't previously<br>
> > monitoring.<br>
> > These commands do this for historical reasons. multipathd<br>
> wasn't<br>
> > originally in charge of creating multipath devices, multipath<br>
> 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<br>
> worked<br>
> > this way since RHEL4, so possibly "add map" should actually<br>
> 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>
> ;<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<br>
> number of<br>
> > active paths. These are paths that the kernel can use. The<br>
> "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<br>
> two, this<br>
> > will say 2, as expected.<br>
> ><br>
> > > We would like to know if the test cases are valid and if<br>
> 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";<br>
> multipathd<br>
> > > -k'reinstate path sdc'; multipathd -k"show paths";<br>
> > > > [ 3962.708523] device-mapper: multipath: Failing path<br>
> 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] ..........<br>
> 1/20 <br>
> > <==CHECK<br>
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........<br>
> 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>
> > > You have answered that this is a design issue. But we have<br>
> heard<br>
> > from our<br>
> > > test team that the same test case works in RHEL6. Did you<br>
> observe<br>
> > it?<br>
> > > I am also finding that the test cases fail because we are<br>
> trying<br>
> > to do<br>
> > > multiple commands at one shot. Please share your thoughts<br>
> 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<br>
> updated in<br>
> > RHEL6. Like I said before, what it currently does, although<br>
> correct,<br>
> > is confusing, and perhaps we need a different checker state for<br>
> 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 class="">> > > <[1][3][4]<a href="mailto:tejaswinipoluri3@gmail.com">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 class="h5">> > > <[2][4][5]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a>> wrote:<br>
> > ><br>
> > > On Mon, May 18, 2015 at 02:09:27PM +0530, Tejaswini<br>
> Poluri<br>
> > wrote:<br>
> > > > Hii,<br>
> > > > We are trying to test multipath setup in our<br>
> target and<br>
> > tried the<br>
> > > various<br>
> > > > commands of multipathd demaon and we find the<br>
> following<br>
> > error:<br>
> > > > root@x86-generic-64:~# multipathd -k"fail path<br>
> 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] ..........<br>
> 1/20 <br>
> > <<<===<br>
> > > CHECK<br>
> > > > 5:0:0:1 sdd 8:48 1 [active][ready] XX........<br>
> 4/20<br>
> > > > sdc path becomes [active][ready] only after the<br>
> polling<br>
> > interval<br>
> > > but not<br>
> > > > immediately after the reinstate path command. <br>
> > > > I am observing this in latest multipath tools in<br>
> ubuntu<br>
> > machine<br>
> > > as well.<br>
> > > > Please let me know if its a known issue or if I<br>
> am doing<br>
> > > something wrong.<br>
> > > > Regards.<br>
> > > > Tejaswini<br>
> > ><br>
> > > the reinstate command is supposed to reinstate the<br>
> device<br>
> > with the<br>
> > > kernel, and it does that. The checker state doesn't<br>
> change<br>
> > until the<br>
> > > next time that the path is checked. I agree that it's<br>
> odd<br>
> > that the<br>
> > > check state switches to faulty as soon as you fail the<br>
> path,<br>
> > but it<br>
> > > doesn't switch back until the next check after you<br>
> reinistate<br>
> > it.<br>
> > ><br>
> > > The issue is that multipathd needs to override the<br>
> checker<br>
> > output,<br>
> > > so that a failed path won't be immeditately<br>
> reinstated. Once<br>
> > the<br>
> > > path comes back, multipathd wants to record the switch<br>
> in the<br>
> > checker<br>
> > > thread, so that it can refresh path information what<br>
> wasn't<br>
> > > automatically done when the path was reinstated. <br>
> However, it<br>
> > may make<br>
> > > more sense to have a different checker state for when<br>
> the<br>
> > device is<br>
> > > in the failed state, so that it's obvious that the<br>
> checker<br>
> > state is<br>
> > > being overruled.<br>
> > ><br>
> > > -Ben<br>
> > ><br>
> > > > --<br>
> > > > dm-devel mailing list<br>
</div></div>> > > > [3][5][6]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > > ><br>
> [4][6][7]<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][8]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > > <br>
> [6][8][9]<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][10]<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> > > 2. mailto:[10][11]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> > > 3. mailto:[11][12]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > > 4.<br>
> [12][13]<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][14]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > > 6.<br>
> [14][15]<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:[16]<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> > 2. mailto:[17]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> > 3. mailto:[18]<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> > 4. mailto:[19]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> > 5. mailto:[20]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > 6. [21]<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> > 7. mailto:[22]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > 8. [23]<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:[24]<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> > 10. mailto:[25]<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> > 11. mailto:[26]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > 12. [27]<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:[28]<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> > 14. [29]<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:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 2. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 3. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 4. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 5. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 6. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 7. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 8. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 9. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 10. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 11. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 12. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 13. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 14. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 15. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 16. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 17. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 18. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 19. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 20. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 21. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 22. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 23. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 24. mailto:<a href="mailto:tejaswinipoluri3@gmail.com">tejaswinipoluri3@gmail.com</a><br>
> 25. mailto:<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a><br>
> 26. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 27. <a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
> 28. mailto:<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
> 29. <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>
<br>
</blockquote></div><br></div>