On 05/05/2016 02:41 PM, Paul Mackerras wrote: > On Thu, May 05, 2016 at 10:01:13AM +0200, Hannes Reinecke wrote: >> On 05/05/2016 05:50 AM, Paul Mackerras wrote: >>> On Wed, May 04, 2016 at 12:04:16PM +0200, Hannes Reinecke wrote: > ... >>>> Nearly. >>>> The thing is, a T-10 vendor specific ID is _supposed_ to be an ASCII >>>> string. So I'd rather have it decoded as such. >>> >>> Do we need to defend against non-printing characters in the string? >>> >> I really would like to stick to ASCII output here, as most vendors put a >> meaningful string in here. >> Those who don't we should be going with the '.' normal method and print >> a dot '.' instead. >> (Can't we fix up snprintf do do it for us? Would be soo cool ...) >> >>>> And we're missing decoding for 'vendor-specific' ID, too. >>> >>> There's no guarantee that this would be ASCII, right? So would you >>> print it in hex? >>> >> Yes, that's the plan here. >> >>> Also, is there a preference between these types? For example, is an >>> 8-byte EUI-64 preferable to a vendor-specific ID of any length? >>> >> Yes. I'd treat T10 vendor ID descriptors with the lowest preference >> (irrespective of the length), eclipsed (sic) only by the truly vendor >> specific ones. > > Well, the disks on my system all have the same vendor-specific ID, > unfortunately -- a '0' followed by 19 spaces. Here are the > designators for all the disks on my system: > > scsi 0:2:0:0: 02 01 00 20 'IBM IPR-0 5EC4AB0000000020' > scsi 0:2:0:0: 02 00 00 14 '0 ' > scsi 0:2:1:0: 02 01 00 20 'IBM IPR-0 5EC28C0000000080' > scsi 0:2:1:0: 02 00 00 14 '0 ' > scsi 0:2:2:0: 02 01 00 20 'IBM IPR-0 5EC28C0000000060' > scsi 0:2:2:0: 02 00 00 14 '0 ' > scsi 0:2:3:0: 02 01 00 20 'IBM IPR-0 5EC28C0000000040' > scsi 0:2:3:0: 02 00 00 14 '0 ' > scsi 0:2:4:0: 02 01 00 20 'IBM IPR-0 5EC28C0000000020' > scsi 0:2:4:0: 02 00 00 14 '0 ' > scsi 0:2:5:0: 02 01 00 20 'IBM IPR-0 5EC28C00000000C0' > scsi 0:2:5:0: 02 00 00 14 '0 ' > scsi 0:2:6:0: 02 01 00 20 'IBM IPR-0 5EC28C00000000A0' > scsi 0:2:6:0: 02 00 00 14 '0 ' > My all time favourite here is HP SmartArray, which has this id:
01 03 00 10 600508b1001cc041769dcf27a752f8c2 01 00 00 04 00000000 Hence the logic to select the 'best' ID; any of the NAA or EUI variants are (more-or-less) guaranteed to give you a valid result. T-10 and Vendor-specific variants, OTOH, do not have a guarantee to be even parseable; I've seen a very wide interpretation area of them meaning of 'ASCII'... >> And actually I would make the vendor-specific decoding the default >> entry, too, as we might come across some other descriptors which we >> cannot decode (yet). And by having a default method for decoding we >> ensure to always be able to come up with an ALUA identification. >> Otherwise we might end up in the same situation as we're in now. > > What would happen if we pick a designator which is not unique across > different disks? Would we think that they were all the same disk? > This is why I've implemented the selection mechanism. Any of the NAA or EUI variants are guaranteed to the unique; I've yet to see a vendor to get this wrong. T-10 and vendor-specific variants, however, have a habit to be _not_ unique, without us being able to tell if they are. (Which was the reason why I've omitted decoding for these). Meanwhile I've posted two patches, one for not failing ALUA when no VPD identifaction could be retrieved, and another one for properly decoding T-10 vendor identifications. Can you please test them and see if you issue is resolved? Thanks. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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
