[CentOS] stale dm-multipath mappings

Eugene Vilensky wrote:
> Greetings,
>
> I've hit this exact 'bug':
>
> https://bugzilla.redhat.com/show_bug.cgi?id=491311
>
> I need to remove the mappings manually. I assume this is done via 'multipath
> -F' followed by a 'multipath -v2' ?  Has anyone experienced doing this on a
> production system?  We can do it during hours of low activity, but we would
> prefer to keep the databases on this host online at the time.  The LUNs
> themselves are completely removed from the host and are not visible on the
> HBA bus.

Just wondering what sort of impact this has to your system? If the
paths are gone they won't be used, so what does it matter?

I have a couple batch processes that run nightly:

- One of them takes a consistent snapshot of a standby mysql database
  and exports the read-write snapshot to a QA host nightly

- The other takes another consistent snapshot of a standby mysql
  database and exports the read-write snapshot to a backup server


In both cases the process involves removing the previous snapshots
from the QA and backup servers respectively, before re-creating new
snapshots and presenting them back to the original servers on the
same LUN IDs. Part of the process I do delete *all* device mappings
for the snapshotted luns on the destination servers with these
commands:

        for i in `/sbin/dmsetup ls | grep p1 | awk '{print $1}'`; do
                dmsetup remove $i;
        done

        for i in `/sbin/dmsetup ls | awk '{print $1}'`; do
                dmsetup remove $i;
        done

I just restart the multipathing service after I present new LUNs
to the system. Both systems do this daily and have been for about
two months now and it works great.

In these two cases currently I am using VMWare raw device mapping
on the remote systems so while I'm using multipath, there is only
1 path(visible to the VM, the MPIO is handled by the host). Prior
to that I used software iSCSI on CentOS 5.2 (no 5.3 yet), and I
did the same thing, I did the same thing because I found restarting
software iSCSI on CentOS 5.2 to be unreliable(more than one kernel
panic during testing). The reason I use MPIO with only 1 path is
so that I can maintain a consistent configuration across systems,
don't need to worry about who has one path or who has 2 or who
has 4, treat them all the same, since multipathing is automatic.

On CentOS 4.x with software iSCSI I didn't remove the paths I just
let them go stale. I restarted software iSCSI and multipath as
part of the snapshot process(software iSCSI is more solid as far
as restarting goes under 4.x, had two panics in 6 months with multiple
systems restarting every day). Thankfully I use LVM because the device
names changed all the time, at some point I was up to like /dev/sddg.

But if your removing dead paths, or even restarting multipath on
a system to detect new ones I have not had this have any noticeable
impact to the system production or not.

I think device mapper will even prevent you from removing a device
that is still in use.

[root at dc1-backup01:/var/log-ng]# dmsetup ls
350002ac005ce0714       (253, 0)
350002ac005d00714       (253, 2)
350002ac005d00714p1     (253, 10)
350002ac005cf0714       (253, 1)
350002ac005d10714       (253, 4)
350002ac005ce0714p1     (253, 7)
san--p--mysql002b--db-san--p--mysql002b--db     (253, 17)
350002ac005d10714p1     (253, 9)
350002ac005d20714       (253, 3)
san--p--mysql002b--log-san--p--mysql002b--log   (253, 13)
san--p--pd1mysql001b--log-san--p--pd1mysql001b--log     (253, 14)
san--p--mysql001b--log-san--p--mysql001b--log   (253, 16)
350002ac005d30714       (253, 5)
350002ac005cf0714p1     (253, 8)
350002ac005d20714p1     (253, 6)
san--p--pd1mysql001b--db-san--p--pd1mysql001b--db       (253, 12)
san--p--mysql001b--db-san--p--mysql001b--db     (253, 15)
350002ac005d30714p1     (253, 11)

[root at dc1-backup01:/var/log-ng]# dmsetup remove 350002ac005d20714p1
device-mapper: remove ioctl failed: Device or resource busy
Command failed

nate