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@xxxxxxx +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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
