When multipathd fails to remove a path or a map, it was printing "ok"
instead of "fail", and exitting with a 0 return code. Now it prints
"fail" and exits with a 1, like it does when other commands fail.
Signed-off-by: Benjamin Marzinski
---
multipathd/cli_handlers.c | 8
multipathd/ma
The SCSI spec is pretty vague on exactly what the tpgs pref bit should
guarantee. In the past, the alua prioritizer has put paths with the pref
bit set in their own priority group, and some users complained.
Currently, the alua prioritizer puts paths with the tpgs pref bit set in
the highest priori
There are now more than 32 keywords for the multipathd client commands.
Since these are represented by a bit flags, multipathd needs more than
32 bits for the client command keycodes. However, multipath is currently
using unsigned long for these. This makes some client commands work
incorrectly on
Currently, running the alua prioritizer on a path causes 5 ioctls on
many devices. get_target_port_group_support() returns whether alua is
supported. get_target_port_group() gets the TPG id. This often takes two
ioctls because 128 bytes is not a large enough buffer size on many
devices. Finally, g
lvm needs PV devices to not be suspended while the udev rules are
running, for them to be correctly identified as PVs. However, multipathd
will often be in a situation where it will create a multipath device
upon seeing a path, and then immediately reload the device upon seeing
another path. If mu
Multipath has an issue with user_friendly_names set in the initramfs.
If the bindings are in the initramfs bindings file, it will create them,
and it may use bindings that are different than the ones in the regular
file system. Once multipathd starts up in the regular file system, it
will try to r
Ideally, udev will be able to grab the wwid when a path device is
discovered, but sometimes this isn't possible. In these cases, the
best thing that could happen would be for udev to actually get the
information, and add it to its database. This patch makes multipath
retrigger uevents a limited num
multipathd.service can start up and run just fine without
blk-availability.service. It is only necessary to coordinate shutdown
order in certain multipath setups (over iscsi for instance). Thus,
instead of "Requires", multipathd.service should use "Wants"
Signed-off-by: Benjamin Marzinski
---
mu
The multipath.conf man page gave the incorrect default for
queue_without_daemon. The multipath usage output listed the -p option
twice. And multipath was misspelled in an mpathpersist error message.
This patch fixes these issues.
Signed-off-by: Benjamin Marzinski
---
libmpathpersist/mpath_persis
When kpartx is modifies devices (either by removing them, or
reloading them), it doesn't first verify that the device really
is a partition of the expected device. If a dm device just happens
to have the same name as a kpartx created device would, kpartx can
either delete that device or remap it,
If kpartx partition devices are in-use, multipath will not be able to
perform a non-deferred remove of the multipath device. So, before
starting the remove, multipath should verify that none of the partition
devices are currently in-use.
Signed-off-by: Benjamin Marzinski
---
libmultipath/devmap
Other programs would like to communicate with multipathd to issue
command or check status. Instead of having them exec multipathd,
I've pulled the code that sends commands and receives replies from
multipathd into its own library. I've made the multipath tools use
this library internally as well.
/var/run is now usually a symlink to /run. If /var is on a separate
filesytem, when multipathd starts up, it might end up writing to
/var/run before the /var filesytem is mounted and thus not have its
pidfile accessible at /var/run afterwards. On most distrubutions /run
is now a tmpfs and should
The PAD and PRINT macros are multi-line macros that aren't enclosed in
braces. This means that if they are used as single line code blocks
with no braces, they won't work correctly. This is currently happening
with the PAD macro, but should be fixed in both.
Signed-off-by: Benjamin Marzinski
---
Right now, multipathd ignores failures from pidfile_create. This means
that multiple multipathd processes can be running at the same time. If
someone runs "multipathd" and doesn't add a command after it, a new
process will be created, even if one is already running. To avoid this,
multipathd needs
multipath was setting LIBUDEV_API_RECVBUF in the makefile if
udev_monitor_set_resolve_buffer_size existed. However the correct
fuction name (and the one used in the code) is
udev_monitor_set_receive_buffer_size. As a result, multipath was never
setting the receive buffer size. This patch simply fix
Here's a bunch of miscellaneous multipath patches. The first couple are
resends, with the following changes:
multipathd: use /run instead of /var/run
-
Added Makefile code to verify that /var/run is actually a symlink
retrigger uevents to try and get the u
When multipath relies on the wwids file to determine whether a device is
a multipath path (with "multipath -c"), it will fail the first time a
new multipathable device is discovered, since the wwid clearly won't be
in the wwids file. This is usually fine. Multipath will still set
itself up on the
On Thu, 24 Mar 2016, Joe Thornber wrote:
> On Tue, Mar 15, 2016 at 01:45:15AM +, Eric Wheeler wrote:
> > Hi Joe,
> >
> > Please review the patch below when you have a moment. I am interested in
> > your feedback, and also interested in having this functionality merged
> > upstream. This w
在 16/3/28 下午12:00, Liuhua Wang 写道:
> Hi List,
>
> I have a question that I think maybe you can give me some idea.
>
> I have two devices with different sector size: 512B and 4096B.
>
> - SOURCE DEVICE (mdos lvm partiton)
> #parted /dev/sdb
> Model: ATA SATADOM-SL 3ME (scsi)
> Disk /dev/sdb: 32.0
20 matches
Mail list logo
