[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9a96d36b-6d0d-e709-b623-be2abc77d869@suse.com>
Date: Fri, 25 Nov 2016 09:02:34 +0100
From: Hannes Reinecke <hare@...e.com>
To: Sylvain Munaut <s.munaut@...tever-company.com>,
LKML <linux-kernel@...r.kernel.org>
Cc: Paul Mackerras <paulus@...abs.org>,
Bart Van Assche <bart.vanassche@...disk.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: Regarding "scsi_lib: Decode T10 vendor IDs"
d230823a1c4c3e97afd4c934b86b3975d5e20249
On 11/24/2016 04:48 PM, Sylvain Munaut wrote:
> Hi,
>
>
> Regarding this commit :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d230823a1c4c3e97afd4c934b86b3975d5e20249
>
> Looking at both the code and the comment, it seems to me you wanted
> 'T10' id to be a last resort if nothing else was available.
>
> If that was the intent, it's not working ...
>
> I have a Samsung 850 Pro SSD that has the NAA identifier after the T10
> one in the vpd_pg83 and so it's returning the T10 now because it's
> longer.
>
Hmm.
> Did I misunderstand the intent ? Or is it a bug ? (for the latter, I
> can write a patch myself, I just didn't want to loose my time if I
> misunderstood).
>
The T10 identifier should _always_ be the last resort; anything is
better than that :-)
But for NAA we have to check the length, as I've come across an array
which will (errorneously) report _two_ NAA identifiers, and only the
longer one of them will be providing the correct identification.
The other one is in fact the NAA for the target port, and thus identical
for all LUNs from that port :-(
So yeah, the intention was not to prefer a longer T10 to a NAA identifier.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@...e.com +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
Powered by blists - more mailing lists