Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs

[Hannes Reinecke <hare@suse.de>]

On 03/07/2014 12:01 PM, James Bottomley wrote:
> On Fri, 2014-03-07 at 11:51 +0100, Hannes Reinecke wrote:
>> On 03/07/2014 11:39 AM, James Bottomley wrote:
>>> On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote:
>>>> So the only 'proper' solution would be to add a bitmap of supported
>>>> pages; however, this would be 256 bits = 32 bytes of additional
>>>> space required for struct sdev.
>>>> Which I'm a bit reluctant do to, as it'll be a sparse array in most
>>>> cases, adding to quite some wasted space.
>>>
>>> Why per sdev?  Isn't it per target?  The supported EVPD page list
>>> shouldn't really vary for luns of the same target unless something very
>>> strange is happening in the array.
>>>
>> Spec says it's per LUN:
> 
> Specs say a lot of "interesting" things.  The question is what's common
> practise in the field.
> 
>> 7.8.16 Supported VPD Pages VPD page
>> The Supported VDP Pages VPD page contains a list of the VPD page
>> codes supported by the logical unit (see
>> table 637).
>>
>> so we shouldn't really make any assumptions about what might be
>> sensible or strange.
> 
> The cardreader case is the one I think causes problems for this.  Going
> completely the opposite direction, why do we need to cache this at
> all? ... it's fairly simple to request each time and it avoids worrying
> about the data changing because of a change in the array.
> 
Storage arrays more often than not do this, too. Especially those
which export a management device.
(block-device specific VPD pages really do not make sense on a
management device)

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