Subscribe

LUN resize isn't always reported to iSCSI clients

I'm trying to debug something related to iSCSI LUN resizing.

In our setup we use Debian Linux 8 (jessie) with Open-iSCSI and multipath-tools connected to a FAS2552 (ONTAP 8.3.2RC2) device.
When we resized our LUN from 6 TiB to 14 TiB yesterday some of the paths got in a weird state.

 

We noticed that the iSCSI clients (the Debian machines) detect the resize:

 

kernel: [5606835.845712] sd 1:0:0:0: Capacity data has changed
kernel: [5606842.329394] sd 2:0:0:1: Capacity data has changed

This is detected because the FAS2552 device is reporting this via iSCSI ("2A 09 CAPACITY DATA HAS CHANGED").

For some reason we got in this situation:

 

$ multipath -l
...
size=14T features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:0 sdc 8:32 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- #:#:#:# -   #:#  active undef running

I'm trying to reproduce this issue by creating a new 50G LUN and resizing the LUN, but the "Capacity data has changed" logline doesn't appear in our logs when we execute the resize.

 

In which case does a FAS2552 device report a resize of a LUN exactly? Or in other words, why doen't it report the resize on my 2nd LUN as it did on my 1st yesterday?

Re: LUN resize isn't always reported to iSCSI clients

We've been debugging this issue a bit more.

 

  1. We found out that the multipath issue is related to https://bugs.debian.org/580972 which is solved in multipath-tools/0.5.0+git0.770e6d0d-3.
  2. By tcpdumping we've been able to confirm that the FAS2552 device is sending the "2A 09 CAPACITY DATA HAS CHANGED" message (SCSI Response (Check Condition) LUN:0x00 - Additional Sense Code+Qualifier: Unknown (0x2a09)). It might be an issue in the Linux kernel, Debian 3.16.36-1+deb8u1 in this case. This could already have been solved in later versions of th Linux kernel. We'll report back to this forum post when we upgrade to Debian 9 (Stretch) and the issue is still there and bothering us.