opensuse / multipath-tools-pre2021

Old (pre-2021) SUSE/SLES fork of Linux multipath tools. See github.com/openSUSE/multipath-tools for current code.

multipath-tools for Linux

---

https://github.com/opensvc/multipath-tools

This package provides the following binaries to drive the Device Mapper multipathing driver:

• multipath - Device mapper target autoconfig.
• multipathd - Multipath daemon.
• mpathpersist - Manages SCSI persistent reservations on dm multipath devices.
• kpartx - Create device maps from partition tables.

Releases

To get a specific X.Y.Z release, use one of the following method:

Git

git clone https://github.com/opensvc/multipath-tools.git
cd multipath-tools
git tag
git archive --format=tar.gz --prefix=multipath-tools-X.Y.Z/ X.Y.Z > ../multipath-tools-X.Y.Z.tar.gz

Direct download

wget "https://github.com/opensvc/multipath-tools/archive/X.Y.Z.tar.gz" -O multipath-tools-X.Y.Z.tar.gz

Browser

Go to: https://github.com/opensvc/multipath-tools/tags Select a release-tag and then click on "zip" or "tar.gz".

Source code

To get latest devel code:

git clone https://github.com/opensvc/multipath-tools.git

Github page: https://github.com/opensvc/multipath-tools

Add storage devices

Follow the instructions in the libmultipath/hwtable.c header.

Mailing list

(subscribers-only) To subscribe and archives: https://www.redhat.com/mailman/listinfo/dm-devel Searchable: https://marc.info/?l=dm-devel

Changelog

pre-0.4.5: https://web.archive.org/web/20070309224034/http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=ChangeLog post-0.4.5: https://github.com/opensvc/multipath-tools/commits/master

Maintainer

Christophe Varoqui [email protected] Device-mapper development mailing list [email protected]

Licence

The multipath-tools source code is covered by several different licences. Refer to the individual source files for details. Source files which do not specify a licence are shipped under LGPL-2.0 (see LICENSES/LGPL-2.0).

multipath-tools-pre2021's Issues

Compile error: ‘major’ is not a function or function pointer

Hi,
Here is the complete error:

make -j7 -l8 CC=x86_64-pc-linux-gnu-gcc LIBDM_API_FLUSH=1 SYSTEMD=226
(...)
x86_64-pc-linux-gnu-gcc -c -O2 -g -pipe -Wall -Wextra -Wformat=2 -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -DLIB_STRING=\"lib64\" -DRUN_DIR=\"run\" -I../libmultipath -I../libmpathpersist -I../libmpathcmd *.c
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<built-in>: note: this is the location of the previous definition
mpath_persist.c: In function ‘mpath_persistent_reserve_in’:
mpath_persist.c:175:10: error: called object ‘major’ is not a function or function pointer
  major = major(info.st_rdev);
          ^
mpath_persist.c:161:6: note: declared here
  int major, minor;
      ^
mpath_persist.c:176:10: error: called object ‘minor’ is not a function or function pointer
  minor = minor(info.st_rdev);

GCC 7.3.0

How is this int major; major = major(...) even supposed to work? %)

In some IPSAN, get_target_port_group_support should be called before get_target_port_group

In function get_alua_info from libmultipath/prioritizers/alua.c.
For now logic, get_alua_info call get_target_port_group first, if get_target_port_group return value tpg >= 0, get_target_port_group_support will not be called, this logic is commited in d7ee31d.

When I use multipath to visit a IPSAN, I modified my code, calling get_target_port_group_support after calling get_target_port_group even if return value tpg >= 0, actually, get_target_port_group_support return TPGS_NONE, it is weird, it could get TPG while it does not support TPG.

In common logic, we should get capability before we get some featurn value, I think it is more reasonable to call get_target_port_group_support first, if TPG is suported, then call get_target_port_group.
thanks a lot.

Multipathd ignoring dev_loss_tmo

Hello guys,

I am having an issue where my systems' Multipath daemon is ignoring dev_loss_tmo setting.

cat /etc/multipath.conf | grep dev_loss_tmo

                dev_loss_tmo 15

This is the value currently being used by the system:

for f in /sys/class/fc_remote_ports/rport-*/dev_loss_tmo; do d=$(dirname $f); echo $(basename $d):$(cat $d/node_name):$(cat $f); done

rport-3:0-0:0x5742b0f00007c500:15
rport-3:0-1:0x5742b0f00007c500:15
rport-3:0-2:0x5000097408369800:30
rport-3:0-3:0x5742b0f00007c500:15
rport-3:0-4:0x200800a098b39200:2147483647
rport-3:0-5:0xffffffffffffffff:16
rport-3:0-6:0x500009757804cbff:30
rport-4:0-0:0x5742b0f00007c500:15
rport-4:0-1:0x5742b0f00007c500:15
rport-4:0-2:0x5000097408369800:30
rport-4:0-3:0x5742b0f00007c500:15
rport-4:0-4:0x200800a098b39200:2147483647
rport-4:0-5:0xffffffffffffffff:16
rport-4:0-6:0x500009757804cbff:30
rport-5:0-0:0x5742b0f00007c500:15
rport-5:0-1:0x5742b0f00007c500:15
rport-5:0-2:0x5742b0f00007c500:15
rport-5:0-3:0x5000097408369800:30
rport-5:0-4:0x200800a098b39200:2147483647
rport-5:0-5:0xffffffffffffffff:16
rport-5:0-6:0x500009757804cbff:30
rport-6:0-0:0x5742b0f00007c500:15
rport-6:0-1:0x5742b0f00007c500:15
rport-6:0-2:0x5000097408369800:30
rport-6:0-3:0x5742b0f00007c500:15
rport-6:0-4:0x200800a098b39200:2147483647
rport-6:0-5:0xffffffffffffffff:16
rport-6:0-6:0x500009757804cbff:30

I am using package multipath-tools-0.4.9-109.1.

Can you please help me?

Kind regards,

the performance of small I/Os

Respected Maintainers,
Sorry to bother you! I really admire you for your excellent work on multipath-tools. I am a storage fan too, although I'm just a green hand. Now, there are some challenging problems about multipath-tools in front of me, and I am eager to get your help.
Here is the question. My storage server is a dual-controller machine with RHEL 7. You know, in certain circumstances, they call it two-storage-processor(SP). I map one LUN out by targetcli(which used to configure the LIO) through the two SPs independently, and manage the mapped devices by multipath software in another host server. Logged in through iscsiadm, I get two(or more) devices in the host server, just name them /dev/sdc and /dev/sdd for example, and multipath combines them into one under /dev/mapper, just name it /dev/mapper/mpathb for example. Then I write some data into /dev/mapper/mpathb in the unit of 4KB, and find the bandwidth is not very high. If this could be accepted, the following thing maybe not. When I write some data into /dev/sdc, the bandwidth is much higher. Then I change the storage server, use a dual-controller machine of EMC instead, the result is much better. the difference of bandwidth between /dev/sdc (I call it iSCSI LUN) and /dev/mapper/mpathb (I call it multipath LUN)is almost negligible. And another phenomenon is that even with my own dual-controller machine, the the difference of bandwidth between the iSCSI LUN and the multipath LUN get reduced as the unit of I/O becomes bigger, like 1MB.
During the test, the host server and its configuration keep same. So I think the storage is the point, especially the LIO target driver, but I don't know how and why.
I trace the I/O, and find when writing the iSCSI LUN -- /dev/sdc, the small I/Os(like 4KB) combine into a bigger one by the Linux I/O Elevator Scheduler(it's the elv_merge() function in kernel for specific) in the host server, but when it occur to the multipath LUN -- /dev/mapper/mpathb, the small I/Os don't combine.
So, I want to optimize the performance of small I/Os, but don't know how to, because I don't know why.

Can you help me with the questions? I will appreciate it very much.Thank you.