Did you run

# multipath -f <device_name>

instead of

# multipath -f <path_to_device>

multipath was recently fixed to work with a path to the device. Before that, removing by path failed.

Otherwise, could you try checking with lsof and fuser to make sure the device isn't in use by some process.

You could also look at

/sys/block/<dm-id>/holders/

If you have kpartx devices, could you try forcibly removing them with

# kpartx -d <path_to_device>

and then try removing the multipath device.  If that works, then there would appear to be a bug dealing with the kpartx partitions, which are built on top of the device.

Hi Ben,

thanks for your reply.

- i did run 

# multipath -f <device_name>

and not

# multipath -f <path_to_device>

- lsof /dev/mapper/<device name> --> empty

- ls /sys/block/dm-<number>/holders/ --> empty

there were no partitions on the lun, so i guess kpartx isnt involved

any other things to check?

regards, ralf

Hrm... How about this. Can you run

# dmsetup info <device_name>

Is Open count 0? If so then multipath should be able to remove it.  If not, then something is holding onto the device according to the kernel, and multipath will not be able to remove it.

If Open count is 0, you can run

# dmsetup remove <device_name>

To remove the device.  This shouldn't change anything at all, but you can run

# service multipathd stop

to stop multipathd if it's running, just to be certain that it has nothing to do with the open device.

dmsetup info <device_name> shows:

....
Open count:        1
....

how can this be explained, as lsof did not find any open files on that device?

I'm really not sure.

Can you run

# losetup -a

To make sure you don't have a loop device opened on it. And run

# dmsetup table

and make sure that the device isn't listed in another device's table. The problem is that both of these should show up as holders.

Is multipathd running?  If so, could you stop it, and then try removing the device.  I don't have high hopes for this, but it's worth a chance.

Here's a thought.  The only thing I can think of that doesn't make
a device show up in holders or a process show up in fuser or lsof but keeps
the device open is mounting it.  So, my best guess is that it's mounted.

# df

should show you if it's mounted in general.  However, if a process has set up a private namespace it can inherit mounts of devices.  Multipath did this in RHEL 5, and so it was able to keep devices open even when they didn't appear to be
mounted with df.  However in RHEL6, that doesn't happen.  But some other process could be doing it.  I don't have an idea which one it could be.

You could check this by running something like

# grep <device_path> /proc/*/mounts

and seeing if any processes list the device as mounted.

Did you ever figure out what was keeping the device open?

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

There are many reasons why a map may be in use. Without more information I don't have any reason to believe this is a multipath bug.