On 05/11/2015 01:34 PM, Christoph Hellwig wrote:
> On Mon, May 11, 2015 at 12:25:51PM +0200, Hannes Reinecke wrote:
>> The spec wording doesn't explicitly disallowing you from doing so
>> (unless you're using referrals).
>> But in realiter we're using the ALUA device handler only when
>> multipathing is used, which in turn runs on disk devices only.
>> So we can limit ourselves to disk devices, too.
>>
>> Everything else (like tapes or tape changers) will have to
>> implement their own logic anyway; tape support in multipathing
>> with or without ALUA is too horrible to contemplate ...
>
> So what is the problem you're trying to solve here? We were attaching
> to other nodes and so far I haven't heard about that being a problem.
>
> Basically we'll disallow I/O for offlines paths to non-disk devices
> once the ALUA handler is attached, which actually seems useful
> even without a multipath handler on top.
>
I've had far too many issues with ALUA attaching to eg enclosure
devices; some enclosures have the habit of returning 'NOT READY,
CAUSE NOT REPORTABLE' when sending an RTPG to it.
Other (broken) devices set the 'TPGS' bit in the inquiry data,
but fail to implement support for everything else.
Currently we're just doing a retry for these cases, and would
have to wait for the timeout to kick in.
We _could_ implement a dedicated error handling here, but
then we're pretty much guaranteed to miss the odd case.
So I've decided to just skip them altogether.
If you insist we could remove this patch, and straighten out
error handling here.
>>>> + if (sdev->type != TYPE_DISK &&
>>>> + sdev->type != TYPE_RBC &&
>>>> + sdev->type != TYPE_OSD) {
>>>
>>> And does it really allow RBC (but not ZBC)?
>>>
>> Thought so, but I'll have to cross-check.
>> Maybe it's time to implement a 'scsi_is_disk_type()' macro...
>
> If the reason to disallow anything that we can't use dm-mpath on
> both OSD and ZBC in it's current form are excluded. RBC would
> be included, although I doubt there is a multi ported RBC
> device available.
>
As said above; we _could_ drop this patch and update error
handling, but then we'll risk of having more bug reports
due to invalid ALUA implementations.
Might be worth it, though, as then we could get in touch
with the respective vendors. But then, maybe not, as not
every vendor is willing to listen to us...
I don't really have a fixed opinion here; either way is
fine with me.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
