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@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@dc1-backup01:/var/log-ng]# dmsetup remove 350002ac005d20714p1 device-mapper: remove ioctl failed: Device or resource busy Command failed

nate