[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] blacklist issues and more

(1) When I change the multipath config file to blacklist an already
multipathed block device,
I must first remove that device from the active multipath configuration via
"multipath -F" or
"dmsetup remove <map-name>" then run "multipath".  Seems like I should not
have to do
all of this.  A simple invocation of "multipath" after modifying the
multipath configuration file
should do it instead by checking the current configuration and
removing/closing the mapped
device for me if that device is currently in the active multipath

Also, don't we need a multipath(8) capability to remove a specific multipath
mapped device
from the active configuration?

(2) This isn't even sufficient since the multipathd holds an open on each
multipath mapped
device.  One result of this is that the target devices used by the mapped
device are not
available for use by any application which must "claim" them exclusively,
for example,
mount(8) or for use via raw io.  I must kill multipathd before I can use any
of the target
devices by these "claiming" applications.  Seems like multipath should get
to close its open on the newly blacklisted block device.

(3) After experimenting with this stuff on my SuSE SLES 9 SP2 host, while
trying to run
performance tests I got myself into a situation where a multipath mapped
device file referred
to THE WRONG LU.  I had no idea this was happening until I researched why
dd(1) was
writing only half the number of 4kb records to the LU than was a dd(1) to
the native scsi
device path.

This happened because it appears that symbolic links in /dev/disk/by-name to
mapper device files in /dev are NOT cleaned up as a result of running
"multipath -F",
"dmsetup remove <map-name>, or "dmsetup remove_all".  A subsequent
invocation of
multipath will not necessarily assign multipath mapped devices to the same
device mapper
minor instances (for example, if one or more of them are blacklisted after
the remove step)
causing the stale symbolic links in /dev/disk/by-name to refer to the wrong
device file in /dev.

An invocation of "multipath -F" did cleanup device files in /dev on my Red
Hat AS 4 host
but an invocation of "dmsetup remove <map-name>" did not.  I was loath to
with "dmsetup remove_all" on my Red Hat host since my root device on that
host is on
a device mapper LVM2 logical volume.  Otherwise, I suspect that this command
fail to clean up device files in the same way "dmsetup remove_all" failed.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]