Bug 491311 - [NetApp 4.8 bug]dm-multipath does not automatically remove maps corresponding to the deleted LUNs
[NetApp 4.8 bug]dm-multipath does not automatically remove maps corresponding...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
All Linux
medium Severity medium
: rc
: 4.8
Assigned To: LVM and device-mapper development team
Cluster QE
Depends On:
Blocks: 450897
  Show dependency treegraph
Reported: 2009-03-20 07:25 EDT by Naveen Reddy
Modified: 2012-05-22 08:52 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-24 21:45:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Naveen Reddy 2009-03-20 07:25:39 EDT
Description of problem:

On RHEL4.8 host, We have some LUNs mapped to the host and the multipath maps are configured. We then delete some LUNs from the controllers and then remove the corresponding entries on the host. We observe that the the SCSI entries are removed, but the multipath maps are not removed automatically from the host. The stale maps remain on the host and we have to flush the multipath maps manually.

For multipath to automatically remove maps corresponding to deleted luns, the multipathd daemon should receive uevents from the udev regarding the deleted devices and accordingly remove the corresponding multipath maps.

Version-Release number of selected component (if applicable):


Steps to Reproduce:

1. Map a LUN (with 4 FC paths) to the RHEL4.8  host from a NetApp controller. 
2. Do a SCSI bus rescan to detect newly added LUNs by issuing the command for each instance -
 echo '- - -' > /sys/class/scsi_host/<host>/scan
3. Verify that SCSI devices are configured and multipath maps are also configured automatically.
# multipath -ll
mpath2 (360a980004334652f526f4e6846384b59)
[size=6 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [prio=8][active]
 \_ 3:0:0:0 sdc 8:32 [active][ready]
 \_ 4:0:1:0 sdf 8:80 [active][ready]
\_ round-robin 0 [prio=2][enabled]
 \_ 3:0:1:0 sdd 8:48 [active][ready]
 \_ 4:0:0:0 sde 8:64 [active][ready]

4. Now delete the LUNs mapped to this host from the controller.
5. Remove the corresponding entries on the host by issuing the following command on the host -
 $echo 1 > /sys/block/<device>/device/delete
6. Verify that the corresponding entries are removed on the host -
 $cat /proc/partitions
7. Now "multipath -ll" still shows maps corresponding to the deleted LUNs with #:# entries.

# multipath -ll
mpath2 (360a980004334652f526f4e6846384b59)
[size=6 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [active]
 \_ #:#:#:#  -   8:32 [failed][faulty]
 \_ #:#:#:#  -   8:80 [failed][faulty]
\_ round-robin 0 [enabled]
 \_ #:#:#:#  -   8:48 [failed][faulty]
 \_ #:#:#:#  -   8:64 [failed][faulty]

Actual results:

multipath maps are not removed automatically from the host. The multipath maps are still seen with #:# entries.

Expected results:

The maps corresponding to the deleted LUNs have to be automatically removed from the host.

Additonal Info:

In RHEL5.3, dm-multipath does remove maps automatically corresponding to the deleted LUNs.
Comment 1 Andrius Benokraitis 2009-03-20 14:42:31 EDT
Is this a regression from RHEL 4.7 to 4.8 Beta?
Comment 2 Naveen Reddy 2009-03-23 08:13:32 EDT
This issue in seen in RHEL4.7 also.
Comment 3 Naveen Reddy 2009-03-23 08:32:37 EDT

This is a feature request for RHEL4.8.

We have this feature in RHEL5.3, where dm-multipath maps are automatically removed corresponding to the deleted LUNs.
Comment 4 Andrius Benokraitis 2009-03-24 21:45:55 EDT
Naveen, unfortunately we are already past Beta in RHEL 4.8, and no features can be implemented post-Beta. Furthermore, I don't see this making the cut for RHEL 4.9 either, due to its planned strict criteria.
Comment 6 pradipta 2011-02-19 15:49:59 EST
Please provide a solution for this as the Box can not be upgraded to 4.9/5.3

Note You need to log in before you can comment on or make changes to this bug.