Re: [dm-devel] ALUA - rescan device capacity on zero sized block devices

[Hannes Reinecke <hare@suse.de>]

On 06/10/2015 05:02 PM, Ewan Milne wrote:
> On Mon, 2015-04-20 at 07:58 +0200, Hannes Reinecke wrote:
>> On 04/19/2015 12:56 AM, Christophe Varoqui wrote:
>>> About five years ago, we faced a somewhat simular issue with
>>> Symmetrix arrays, where the replicated LU of a SRDF pair (R2) was
>>> flagged read-only by the kernel upon discovery. Splitting the pair
>>> with a symcli command  made the LU read-write from the array
>>> controller point of view, but the Linux kernel would not promote it
>>> read-write dynamically.
>>>
>>> I don't know if the Symmetrix array also use a unit attention to
>>> signal the change to the initiators. If it does, it might be worth
>>> trying to address both the 3par peer persistance and the Symmetrix
>>> SRDF situations.
>>>
>>> On the other hand, if the SRDF R2 rw promotion issue has been fixed
>>> since, the patch might give guidance about where/how to plug the
>>> 3par peer persistance ghost path rescans.
>>>
>> It's not only that; if you are faced with LUNs in standby even the
>> kernel wouldn't detect them properly.
>>
>> I'm currently debugging this issue and will have an update soon(-ish).
> 
> I have a patch set to have the kernel automatically rescan the device
> when the ALUA state changes to an ACTIVE state, if it couldn't read
> capacity when the device was initially probed.  I've had it for a while,
> but I haven't had *any* response from the vendor if it actually works
> with their product, so I haven't posted it to the list for review yet.
> 
Please hold off that patchset.

I've posted the ALUA update patchset a while ago, and are working on
including the suggestions from hch.

Please check if that patchset fixes the issue.

Additionally, I've got some patches for lio-target which will blank
out the READ CAPACITY command when in standby; with that one has an
easy testbed for this kind of issues.

> I did point out to them that the T10 spec does not *prohibit* supporting
> the READ CAPACITY command in the ALUA standby state, which would avoid
> the problem, and is what other vendors seem to do.  However, they then
> raised the issue that if the capacity changes in the standby state then
> they should be generating the capacity changed UA, etc and you can sort
> of see their point of why this gets complicated.
> 
Which is actually not true. The capacity did _not_ change, it's just
the command which isn't supported. If the command was supported and
would have reported a size of '0' in standby _then_ it would have
been a capacity change. But that's not the case here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html