Hide Forgot
Description of problem: Multipath reports path as sucessfully resized after second attempt despite of the size in DM table remains. Version-Release number of selected component (if applicable): - device-mapper-multipath-0.4.9-87.el6.x86_64 - device-mapper-libs-1.02.95-2.el6.x86_64 - device-mapper-1.02.95-2.el6.x86_64 How reproducible: Resizing of multipath device which is on top of two devices with different size results with fail on first attempt but success on second one. Steps to Reproduce: Running on VM where I use two devices grouped to multipath over serial. Devices has different size first 100M second 200M (I know this is ugly hack, but it is quick way how to reproduce it.) 1. Create two device with different size and set same serial number over qemu or libvirt (it works on latest F23 as hypervizor) 2. Configure mpath to group by serial 3. Manually over dmsetup create multipath target. It's important to have the bigger device as first! # dmsetup create mpathe --table "0 204800 multipath 0 0 2 1 round-robin 0 1 1 8:144 1 round-robin 0 1 1 8:64 1" 4. # multipathd -d resize map /dev/mapper/mpathe fail You will get in messages: Apr 18 12:13:44 rhel6-debug kernel: [ 4913.905877] device-mapper: table: 253:2: sde too small for target: start=0, len=409600, dev_size=204800 5. On second attempt: # multipathd -d resize map /dev/mapper/mpathe ok And in logs you will have message like. Apr 18 12:13:47 rhel6-debug multipathd: mpathe: map is still the same size (409600) Apr 18 12:13:48 rhel6-debug multipathd: mpathe: resize map (operator) but the actual size is still the same: # dmsetup table mpathe 0 204800 multipath 0 0 2 1 round-robin 0 1 1 8:144 1 round-robin 0 1 1 8:64 1 Actual results: The mpath is reported as sucesfully resized but the size is still the same. Expected results: It should report fail on every attempt. Additional info: [3:0:4:0] disk QEMU QEMU HARDDISK 2.4. /dev/sde [8:64] [4:0:4:0] disk QEMU QEMU HARDDISK 2.4. /dev/sdj [8:144] [root@rhel6-debug ~]# sg_readcap /dev/sde Read Capacity results: Last logical block address=204799 (0x31fff), Number of blocks=204800 Logical block length=512 bytes Hence: Device size: 104857600 bytes, 100.0 MiB, 0.10 GB [root@rhel6-debug ~]# sg_readcap /dev/sdj Read Capacity results: Last logical block address=409599 (0x63fff), Number of blocks=409600 Logical block length=512 bytes Hence: Device size: 209715200 bytes, 200.0 MiB, 0.21 GB -- Lukas
Fixed this. Multipathd was updating the device size internally, even on failures. So on future attempts, it thought the device was already the new size. Now it keeps the original size, until the resize actually succeeds.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0697.html