Problem Overview
The issue stemmed from a conflict with the multipath device /dev/mapper/mpathch
. The kernel assigned identical paths (e.g., sdmg
, sdfl
, sdmd
, sdft
) to a new LUN, resulting in duplicate device mappings and access conflicts. This caused errors during device scans and prevented the cleanup of the mpathch
device.
Errors Observed
During
pvscan
, errors were encountered when reading the device:These errors indicated that the device could not be properly accessed or read by the system, likely due to the path conflicts.
dmsetup info -c
revealed that:- The device
/dev/mapper/mpathch
was still active with paths assigned. - The logical volume
vgexport-lvexport
was in use, blocking further actions onmpathch
.
- The device
Resolution Steps
Checked Active Devices:
- Used
dmsetup info -c
to identify active devices and locatempathch
and associated logical volumes.
- Used
Removed the Blocking Logical Volume:
- Identified and removed the logical volume
vgexport-lvexport
, which was preventing the unmapping ofmpathch
.
- Identified and removed the logical volume
Forcefully Removed the Multipath Device:
- Used
dmsetup remove -f
to forcibly delete thempathch
device from the device-mapper layer.
- Used
Validation
- Verified that
mpathch
and its associated paths were no longer present using: - Confirmed the system was no longer referencing the conflicting LUN and informed the storage team for reassignment or cleanup.
- After the reload, the new LUN became visible in the system.
Conclusion
The problem was caused by duplicate kernel path assignments for a new LUN, which conflicted with existing device mappings and caused read errors during device scans. By removing the blocking logical volume and forcefully unmapping the multipath device, the issue was resolved, and the system was returned to a clean state.