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