Re: [PATCH 08/16] scsi_dh_alua: parse target device id

[Hannes Reinecke <hare@suse.de>]

On 02/17/2014 03:05 PM, Bart Van Assche wrote:
> On 02/14/14 13:21, Hannes Reinecke wrote:
>> On 02/14/2014 01:09 PM, Bart Van Assche wrote:
>>> On 01/31/14 10:29, Hannes Reinecke wrote:
>>>> +	if (!target_id_size) {
>>>> +		/* Check for EMC Clariion extended inquiry */
>>>> +		if (!strncmp(sdev->vendor, "DGC     ", 8) &&
>>>> +		    sdev->inquiry_len > 160) {
>>>> +			target_id_size = sdev->inquiry[160];
>>>> +			target_id = sdev->inquiry + 161;
>>>> +			strcpy(target_id_str, "emc.");
>>>> +			memcpy(target_id_str + 4, target_id, target_id_size);
>>>> +		}
>>>> +		/* Check for HP EVA extended inquiry */
>>>> +		if (!strncmp(sdev->vendor, "HP      ", 8) &&
>>>> +		    !strncmp(sdev->model, "HSV", 3) &&
>>>> +		    sdev->inquiry_len > 170) {
>>>> +			target_id_size = 16;
>>>> +			target_id = sdev->inquiry + 154;
>>>> +			strcpy(target_id_str, "naa.");
>>>> +			memcpy(target_id_str + 4, target_id, target_id_size);
>>>> +		}
>>>> +	}
>>>
>>> Being able to identify a storage array unambiguously is essential for
>>> the new ALUA device handler algorithm introduced by this patch series.
>>> What if a new storage array is introduced that is not covered by one of
>>> the heuristics in this patch ? Has it been considered to let storage
>>> array identification occur in user space instead of in the kernel ?
>>
>> As noted in the other mail, if we cannot decipher the array
>> identifier the whole thing degrades into one pg per sdev.
>> IE we cannot bunch RTPG / STPG for those.
>> The idea here is that those arrays do not have any limitations,
>> so that no special treatment is required.
>>
>> Adding identifiers from userspace are a bit tricky; there is no
>> actual sysfs structure for the device handler.
>> Which we would need if we were to use these tricks.
> 
> The reason I started asking about the target device ID is because for
> Fusion-io ION devices we also encode the device ID in the INQUIRY
> response (bytes 36..55; left aligned; padded with '\0'). The vendor name
> is "FUSIONIO" and the first three characters of the product name are
> "ION". Can you add  the necessary support in the device identification
> code ? Seems like it's time we get you a pair of those devices for
> testing :-) An example:
> 
> # sg_inq -rl256 /dev/sdb | dd bs=1 count=20 skip=36 2>/dev/null | od -c
> 0000000   U   S   E   2   4   0   F   W   6   5  \0  \0  \0  \0  \0  \0
> 0000020  \0  \0  \0  \0
> 0000024
> 
If the product ID is actually the array identification and not a
generic name, sure.
But if all ION arrays with the same FW level identify itself with
the same identifier it's kinda pointless :-)
Otherwise, yeah, that's easily done.

But you might want to talk to your FW folks; if they were to update
VPD page 0x83 to include an target-specific identifier we'd be all
set ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (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