Bug 352421

I'm experiencing this issue, as well.

I'm using RHEL 4.6.

: server17 42#; multipath -v 2 -d mpath0
reload: mpath0 (360a980004335434e654a48426b467552)
[size=320 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [prio=4]
 \_ 11:0:0:0    sdd 8:48  [active][ready]
 \_ 12:0:0:0    sde 8:64  [active][ready]

: server17 43#; multipath -v 2 mpath0
device-mapper: reload ioctl failed: Invalid argument

What's the status of this? Seemingly the same issue here in 4.6, kernel 2.6.9-55.0.9.ELsmp and dm-multipath 0.4.5-21.0.1.


Resized a FC LUN from 400 to 600 GB and the kernel picks up the size of the new devices:

# dmesg -c
SCSI device sde: 1258291200 512-byte hdwr sectors (644245 MB)
SCSI device sde: drive cache: write through


I tried removing and re-adding one path (deleted the dev node and re-added) but that didn't help as it can't add the 600 GB path to the 400 GB map:

# /sbin/multipath -ll oradbf
oradbf (3600508b400070f7d0000b00000310000)
[size=400 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [prio=110][active]
 \_ #:#:#:#  -   8:16  [failed][faulty]
 \_ 0:0:1:2 sde 8:64  [active][ready]
 \_ 1:0:0:2 sdh 8:112 [active][ready]
 \_ 1:0:1:2 sdk 8:160 [active][ready]


Multipath seems to *want* to increase the multipath map size, but can't:

# /sbin/multipath -v3 -d
0 1258291200 multipath 0 0 1 1 round-robin 0 4 1 8:64 5000 8:80 1000 8:112 5000 8:160 1000
set ACT_RELOAD: size change
device-mapper: reload ioctl failed: Invalid argument

# dmesg -c
device-mapper: device 8:64 too small for target
device-mapper: dm-multipath: error getting device
device-mapper: error adding target to table


Is there a workaround for this or perhaps its fixed in RHEL 5.x?

It seems that a path was submitted mainstream but it was not reviewed by mantainer:
http://thread.gmane.org/gmane.linux.scsi/41623

(In reply to comment #7)
> It seems that a path was submitted mainstream but it was not reviewed by
> mantainer:
> http://thread.gmane.org/gmane.linux.scsi/41623

Hmm this patch was also the solution, it seems, for bug 455692 (https://bugzilla.redhat.com/show_bug.cgi?id=455692)

However, that bug doesn't seem to have a final resolution either.

No, it is not solved (and it's a BIG issue in enterprise environment).
Here:
 https://www.redhat.com/archives/dm-devel/2008-August/msg00033.html
you can find a "unpolished, YMMV, no warranty recipe" to do online resize.
I didn't test it yet.

Suggestion: file a Request-for-Enhancement to Red Hat support, if you have a contract, Bugzilla is not the best place.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Has there been any update on this yet?

This is a ridiculous bug in an enterprise system and we're having to use other operating systems until this is fixed.

*** Bug 479684 has been marked as a duplicate of this bug. ***

With the kernel fixed to allow online resize, this should just work now.
The steps should be:

1. rescan all of your devices (you may need to do the trespass to make sure that
all of the devices are resized)
2. run
# multipath

Now that the kernel can really change the size of the device while it's online, the multipath ioctl should work. This kernel change went into the 2.6.9-78.29.EL
kernel.

However, when testing this, I ran into some issues. They are described in bug 454872.  Once they are resolved. I'm going to close this bug as WORKSFORME

If you can reproduce the problem with the -78.29 or newer kernel, please reopen the bug.

The issue in 454872 has been resolved.  However there may need to be one more step necessary to resize your device without errors.  To resize some LUNs, you need
to temorarily unmap the LUN on your storage device.  In this case, while the LUN is unmapped, any IO that goes to the device will fail if the device isn't set to queue IO when all paths are down (by setting features to "1 queue_if_no_path" or setting no_path_retry to something other than "fail" in multipath.conf)

To avoid this problem on devices that don't queue when all paths are down. You can run dmsetup suspend --noflush <devicename> before you unmap the LUN, and then run
dmsetup resume <devicename> after you remap the LUN, and before you rescan the scsi device.

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
In RHEL 4.8 it is possible to do online resizing of multipath devices. The steps to do this are:

1. Resize your storage
2. Rescan your devices
3. run multipath

multipath will notice the new path size, and correctly resize the multipath device.

However, on some storage devices, it is necessary to unmap a LUN in order to resize it.  In that case, any IO that is issued while the LUN is unmapped will fail, unless your multipath device is set to queue IO when no paths exist.

To avoid this, you can run
# dmsetup suspend --noflush <devicename>
before doing step 1, and then
# dmsetup resume <devicename>
after doing step 1.

This will ensure that no IO goes to the device
while the LUN is unmapped.

Instead of a release note. This information has simply been added to the errata description. I'm closing this bug, since no actual changes were necessary.