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.
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
