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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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]tejaswinipoluri3@xxxxxxxxx> wrote:> > > <[1][2][3]bmarzins@xxxxxxxxxx> 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
> > > >
> > > > 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
> > > > > <[1][3][4][5][6]tejaswinipoluri3@xxxxxxxxx>> > > > <[2][3][4][5]bmarzins@xxxxxxxxxx> 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
> 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@xxxxxxxxxx>
> > > > > > [3][5][6][7][8]dm-devel@xxxxxxxxxx> 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
> > > > > >
> > >
> [4][6][7][8][9]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > --
> > > > > dm-devel mailing list
> > > > > [5][7][8][9][10]dm-devel@xxxxxxxxxx
> > > > >
> > >
> [6][8][9][10][11]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1.
> mailto:[9][10][11][12]tejaswinipoluri3@xxxxxxxxx
> > > > > 2.
> mailto:[10][11][12][13]bmarzins@xxxxxxxxxx
> > > > > 3.
> mailto:[11][12][13][14]dm-devel@xxxxxxxxxx
> > > > > 4.
> > >
> [12][13][14][15]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > > 5.
> mailto:[13][14][15][16]dm-devel@xxxxxxxxxx
> > > > > 6.
> > >
> [14][15][16][17]https://www.redhat.com/mailman/listinfo/dm-devel
> > > >
> > > > References
> > > >
> > > > Visible links
> > > > 1. mailto:[16][17][18]tejaswinipoluri3@xxxxxxxxx
> > > > 2. mailto:[17][18][19]bmarzins@xxxxxxxxxx
> > > > 3. mailto:[18][19][20]tejaswinipoluri3@xxxxxxxxx
> > > > 4. mailto:[19][20][21]bmarzins@xxxxxxxxxx
> > > > 5. mailto:[20][21][22]dm-devel@xxxxxxxxxx
> > > > 6.
> [21][22][23]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 7. mailto:[22][23][24]dm-devel@xxxxxxxxxx
> > > > 8.
> [23][24][25]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 9. mailto:[24][25][26]tejaswinipoluri3@xxxxxxxxx
> > > > 10. mailto:[25][26][27]bmarzins@xxxxxxxxxx
> > > > 11. mailto:[26][27][28]dm-devel@xxxxxxxxxx
> > > > 12.
> [27][28][29]https://www.redhat.com/mailman/listinfo/dm-devel
> > > > 13. mailto:[28][29][30]dm-devel@xxxxxxxxxx
> > > > 14.
> [29][30][31]https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > > References
> > >
> > > Visible links
> > > 1. mailto:[31][32]bmarzins@xxxxxxxxxx
> > > 2. mailto:[32][33]tejaswinipoluri3@xxxxxxxxx
> > > 3. mailto:[33][34]bmarzins@xxxxxxxxxx
> > > 4. mailto:[34][35]tejaswinipoluri3@xxxxxxxxx
> > > 5. mailto:[35][36]bmarzins@xxxxxxxxxx
> > > 6. mailto:[36][37]dm-devel@xxxxxxxxxx
> > > 7. [37][38]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 8. mailto:[38][39]dm-devel@xxxxxxxxxx
> > > 9. [39][40]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 10. mailto:[40][41]tejaswinipoluri3@xxxxxxxxx
> > > 11. mailto:[41][42]bmarzins@xxxxxxxxxx
> > > 12. mailto:[42][43]dm-devel@xxxxxxxxxx
> > > 13. [43][44]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 14. mailto:[44][45]dm-devel@xxxxxxxxxx
> > > 15. [45][46]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 16. mailto:[46][47]tejaswinipoluri3@xxxxxxxxx
> > > 17. mailto:[47][48]bmarzins@xxxxxxxxxx
> > > 18. mailto:[48][49]tejaswinipoluri3@xxxxxxxxx
> > > 19. mailto:[49][50]bmarzins@xxxxxxxxxx
> > > 20. mailto:[50][51]dm-devel@xxxxxxxxxx
> > > 21. [51][52]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 22. mailto:[52][53]dm-devel@xxxxxxxxxx
> > > 23. [53][54]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 24. mailto:[54][55]tejaswinipoluri3@xxxxxxxxx
> > > 25. mailto:[55][56]bmarzins@xxxxxxxxxx
> > > 26. mailto:[56][57]dm-devel@xxxxxxxxxx
> > > 27. [57][58]https://www.redhat.com/mailman/listinfo/dm-devel
> > > 28. mailto:[58][59]dm-devel@xxxxxxxxxx
> > > 29. [59][60]https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > References
> >
> > Visible links
> > 1. mailto:[61]bmarzins@xxxxxxxxxx
> > 2. mailto:[62]bmarzins@xxxxxxxxxx
> > 3. mailto:[63]tejaswinipoluri3@xxxxxxxxx
> > 4. mailto:[64]bmarzins@xxxxxxxxxx
> > 5. mailto:[65]tejaswinipoluri3@xxxxxxxxx
> > 6. mailto:[66]bmarzins@xxxxxxxxxx
> > 7. mailto:[67]dm-devel@xxxxxxxxxx
> > 8. [68]https://www.redhat.com/mailman/listinfo/dm-devel
> > 9. mailto:[69]dm-devel@xxxxxxxxxx
> > 10. [70]https://www.redhat.com/mailman/listinfo/dm-devel
> > 11. mailto:[71]tejaswinipoluri3@xxxxxxxxx
> > 12. mailto:[72]bmarzins@xxxxxxxxxx
> > 13. mailto:[73]dm-devel@xxxxxxxxxx
> > 14. [74]https://www.redhat.com/mailman/listinfo/dm-devel
> > 15. mailto:[75]dm-devel@xxxxxxxxxx
> > 16. [76]https://www.redhat.com/mailman/listinfo/dm-devel
> > 17. mailto:[77]tejaswinipoluri3@xxxxxxxxx
> > 18. mailto:[78]bmarzins@xxxxxxxxxx
> > 19. mailto:[79]tejaswinipoluri3@xxxxxxxxx
> > 20. mailto:[80]bmarzins@xxxxxxxxxx
> > 21. mailto:[81]dm-devel@xxxxxxxxxx
> > 22. [82]https://www.redhat.com/mailman/listinfo/dm-devel
> > 23. mailto:[83]dm-devel@xxxxxxxxxx
> > 24. [84]https://www.redhat.com/mailman/listinfo/dm-devel
> > 25. mailto:[85]tejaswinipoluri3@xxxxxxxxx
> > 26. mailto:[86]bmarzins@xxxxxxxxxx
> > 27. mailto:[87]dm-devel@xxxxxxxxxx
> > 28. [88]https://www.redhat.com/mailman/listinfo/dm-devel
> > 29. mailto:[89]dm-devel@xxxxxxxxxx
> > 30. [90]https://www.redhat.com/mailman/listinfo/dm-devel
> > 31. mailto:[91]bmarzins@xxxxxxxxxx
> > 32. mailto:[92]tejaswinipoluri3@xxxxxxxxx
> > 33. mailto:[93]bmarzins@xxxxxxxxxx
> > 34. mailto:[94]tejaswinipoluri3@xxxxxxxxx
> > 35. mailto:[95]bmarzins@xxxxxxxxxx
> > 36. mailto:[96]dm-devel@xxxxxxxxxx
> > 37. [97]https://www.redhat.com/mailman/listinfo/dm-devel
> > 38. mailto:[98]dm-devel@xxxxxxxxxx
> > 39. [99]https://www.redhat.com/mailman/listinfo/dm-devel
> > 40. mailto:[100]tejaswinipoluri3@xxxxxxxxx
> > 41. mailto:[101]bmarzins@xxxxxxxxxx
> > 42. mailto:[102]dm-devel@xxxxxxxxxx
> > 43. [103]https://www.redhat.com/mailman/listinfo/dm-devel
> > 44. mailto:[104]dm-devel@xxxxxxxxxx
> > 45. [105]https://www.redhat.com/mailman/listinfo/dm-devel
> > 46. mailto:[106]tejaswinipoluri3@xxxxxxxxx
> > 47. mailto:[107]bmarzins@xxxxxxxxxx
> > 48. mailto:[108]tejaswinipoluri3@xxxxxxxxx
> > 49. mailto:[109]bmarzins@xxxxxxxxxx
> > 50. mailto:[110]dm-devel@xxxxxxxxxx
> > 51. [111]https://www.redhat.com/mailman/listinfo/dm-devel
> > 52. mailto:[112]dm-devel@xxxxxxxxxx
> > 53. [113]https://www.redhat.com/mailman/listinfo/dm-devel
> > 54. mailto:[114]tejaswinipoluri3@xxxxxxxxx
> > 55. mailto:[115]bmarzins@xxxxxxxxxx
> > 56. mailto:[116]dm-devel@xxxxxxxxxx
> > 57. [117]https://www.redhat.com/mailman/listinfo/dm-devel
> > 58. mailto:[118]dm-devel@xxxxxxxxxx
> > 59. [119]https://www.redhat.com/mailman/listinfo/dm-devel
>
> References
>
> Visible links
> 1. mailto:bmarzins@xxxxxxxxxx
> 2. mailto:bmarzins@xxxxxxxxxx
> 3. mailto:bmarzins@xxxxxxxxxx
> 4. mailto:tejaswinipoluri3@xxxxxxxxx
> 5. mailto:bmarzins@xxxxxxxxxx
> 6. mailto:tejaswinipoluri3@xxxxxxxxx
> 7. mailto:bmarzins@xxxxxxxxxx
> 8. mailto:dm-devel@xxxxxxxxxx
> 9. https://www.redhat.com/mailman/listinfo/dm-devel
> 10. mailto:dm-devel@xxxxxxxxxx
> 11. https://www.redhat.com/mailman/listinfo/dm-devel
> 12. mailto:tejaswinipoluri3@xxxxxxxxx
> 13. mailto:bmarzins@xxxxxxxxxx
> 14. mailto:dm-devel@xxxxxxxxxx
> 15. https://www.redhat.com/mailman/listinfo/dm-devel
> 16. mailto:dm-devel@xxxxxxxxxx
> 17. https://www.redhat.com/mailman/listinfo/dm-devel
> 18. mailto:tejaswinipoluri3@xxxxxxxxx
> 19. mailto:bmarzins@xxxxxxxxxx
> 20. mailto:tejaswinipoluri3@xxxxxxxxx
> 21. mailto:bmarzins@xxxxxxxxxx
> 22. mailto:dm-devel@xxxxxxxxxx
> 23. https://www.redhat.com/mailman/listinfo/dm-devel
> 24. mailto:dm-devel@xxxxxxxxxx
> 25. https://www.redhat.com/mailman/listinfo/dm-devel
> 26. mailto:tejaswinipoluri3@xxxxxxxxx
> 27. mailto:bmarzins@xxxxxxxxxx
> 28. mailto:dm-devel@xxxxxxxxxx
> 29. https://www.redhat.com/mailman/listinfo/dm-devel
> 30. mailto:dm-devel@xxxxxxxxxx
> 31. https://www.redhat.com/mailman/listinfo/dm-devel
> 32. mailto:bmarzins@xxxxxxxxxx
> 33. mailto:tejaswinipoluri3@xxxxxxxxx
> 34. mailto:bmarzins@xxxxxxxxxx
> 35. mailto:tejaswinipoluri3@xxxxxxxxx
> 36. mailto:bmarzins@xxxxxxxxxx
> 37. mailto:dm-devel@xxxxxxxxxx
> 38. https://www.redhat.com/mailman/listinfo/dm-devel
> 39. mailto:dm-devel@xxxxxxxxxx
> 40. https://www.redhat.com/mailman/listinfo/dm-devel
> 41. mailto:tejaswinipoluri3@xxxxxxxxx
> 42. mailto:bmarzins@xxxxxxxxxx
> 43. mailto:dm-devel@xxxxxxxxxx
> 44. https://www.redhat.com/mailman/listinfo/dm-devel
> 45. mailto:dm-devel@xxxxxxxxxx
> 46. https://www.redhat.com/mailman/listinfo/dm-devel
> 47. mailto:tejaswinipoluri3@xxxxxxxxx
> 48. mailto:bmarzins@xxxxxxxxxx
> 49. mailto:tejaswinipoluri3@xxxxxxxxx
> 50. mailto:bmarzins@xxxxxxxxxx
> 51. mailto:dm-devel@xxxxxxxxxx
> 52. https://www.redhat.com/mailman/listinfo/dm-devel
> 53. mailto:dm-devel@xxxxxxxxxx
> 54. https://www.redhat.com/mailman/listinfo/dm-devel
> 55. mailto:tejaswinipoluri3@xxxxxxxxx
> 56. mailto:bmarzins@xxxxxxxxxx
> 57. mailto:dm-devel@xxxxxxxxxx
> 58. https://www.redhat.com/mailman/listinfo/dm-devel
> 59. mailto:dm-devel@xxxxxxxxxx
> 60. https://www.redhat.com/mailman/listinfo/dm-devel
> 61. mailto:bmarzins@xxxxxxxxxx
> 62. mailto:bmarzins@xxxxxxxxxx
> 63. mailto:tejaswinipoluri3@xxxxxxxxx
> 64. mailto:bmarzins@xxxxxxxxxx
> 65. mailto:tejaswinipoluri3@xxxxxxxxx
> 66. mailto:bmarzins@xxxxxxxxxx
> 67. mailto:dm-devel@xxxxxxxxxx
> 68. https://www.redhat.com/mailman/listinfo/dm-devel
> 69. mailto:dm-devel@xxxxxxxxxx
> 70. https://www.redhat.com/mailman/listinfo/dm-devel
> 71. mailto:tejaswinipoluri3@xxxxxxxxx
> 72. mailto:bmarzins@xxxxxxxxxx
> 73. mailto:dm-devel@xxxxxxxxxx
> 74. https://www.redhat.com/mailman/listinfo/dm-devel
> 75. mailto:dm-devel@xxxxxxxxxx
> 76. https://www.redhat.com/mailman/listinfo/dm-devel
> 77. mailto:tejaswinipoluri3@xxxxxxxxx
> 78. mailto:bmarzins@xxxxxxxxxx
> 79. mailto:tejaswinipoluri3@xxxxxxxxx
> 80. mailto:bmarzins@xxxxxxxxxx
> 81. mailto:dm-devel@xxxxxxxxxx
> 82. https://www.redhat.com/mailman/listinfo/dm-devel
> 83. mailto:dm-devel@xxxxxxxxxx
> 84. https://www.redhat.com/mailman/listinfo/dm-devel
> 85. mailto:tejaswinipoluri3@xxxxxxxxx
> 86. mailto:bmarzins@xxxxxxxxxx
> 87. mailto:dm-devel@xxxxxxxxxx
> 88. https://www.redhat.com/mailman/listinfo/dm-devel
> 89. mailto:dm-devel@xxxxxxxxxx
> 90. https://www.redhat.com/mailman/listinfo/dm-devel
> 91. mailto:bmarzins@xxxxxxxxxx
> 92. mailto:tejaswinipoluri3@xxxxxxxxx
> 93. mailto:bmarzins@xxxxxxxxxx
> 94. mailto:tejaswinipoluri3@xxxxxxxxx
> 95. mailto:bmarzins@xxxxxxxxxx
> 96. mailto:dm-devel@xxxxxxxxxx
> 97. https://www.redhat.com/mailman/listinfo/dm-devel
> 98. mailto:dm-devel@xxxxxxxxxx
> 99. https://www.redhat.com/mailman/listinfo/dm-devel
> 100. mailto:tejaswinipoluri3@xxxxxxxxx
> 101. mailto:bmarzins@xxxxxxxxxx
> 102. mailto:dm-devel@xxxxxxxxxx
> 103. https://www.redhat.com/mailman/listinfo/dm-devel
> 104. mailto:dm-devel@xxxxxxxxxx
> 105. https://www.redhat.com/mailman/listinfo/dm-devel
> 106. mailto:tejaswinipoluri3@xxxxxxxxx
> 107. mailto:bmarzins@xxxxxxxxxx
> 108. mailto:tejaswinipoluri3@xxxxxxxxx
> 109. mailto:bmarzins@xxxxxxxxxx
> 110. mailto:dm-devel@xxxxxxxxxx
> 111. https://www.redhat.com/mailman/listinfo/dm-devel
> 112. mailto:dm-devel@xxxxxxxxxx
> 113. https://www.redhat.com/mailman/listinfo/dm-devel
> 114. mailto:tejaswinipoluri3@xxxxxxxxx
> 115. mailto:bmarzins@xxxxxxxxxx
> 116. mailto:dm-devel@xxxxxxxxxx
> 117. https://www.redhat.com/mailman/listinfo/dm-devel
> 118. mailto:dm-devel@xxxxxxxxxx
> 119. https://www.redhat.com/mailman/listinfo/dm-devel
commit 79ab9090d3fbcdb5844478419135d1390cf548c2
Author: Tejaswini <tejaswinipoluri3@xxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxx>
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@xxxxxxxxx>
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;
}
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
