Re: NAA breakage

["Nicholas A. Bellinger" <nab@linux-iscsi.org>]

On Sun, 2011-09-11 at 15:00 +0100, Chris Boot wrote:
> On 11/09/2011 12:52, Martin Svec wrote:
> > thanks a lot for your comments. Clearly there was a misunderstanding 
> > of who is the vendor that defines what is "vendor-specific" in case of 
> > LIO. Of course, it is easy for me to fix my userspace code to generate 
> > serial numbers without these issues. But I suggest to enforce 
> > vpd_unit_serial restrictions in configfs code because rtslib/lio-utils 
> > is just a referential userspace implementation, not a kernel ABI.
> 
> I feel it's time to add my 2 cents to this discussion. A vendor-specific 
> identifier in my mind could very well be what Martin uses it for, in my 
> opinion - at least according to SPC-3.

To clarify a point wrt to the per device EVPD 0x80 vpd_unit_serial
configfs attribute.  SPC-4 recommends using vpd_unit_serial as part of
the vendor specific identifier for T10 vendor ID based DESIGNATOR in
EVPD 0x83.  This is described in 7.8.5.4 as:

"The organization associated with the T10 vendor identification is
responsible for ensuring that the VENDOR SPECIFIC DESIGNATOR field is
unique in a way that makes the entire DESIGNATOR field unique.
A recommended method of constructing a unique DESIGNATOR field is to
concatenate the PRODUCT IDENTIFICATION field from the standard
INQUIRY data and the PRODUCT SERIAL NUMBER field from the Unit Serial
Number VPD page."

This is what target does for EVPD 0x83 using the T10 vendor designator
variable length method, and as well for modern NAA IEEE Registered
Extended designator using a fixed byte length.

> If the LIO stack cannot handle 
> such use of identifiers the configfs code should refuse to accept such 
> an identifier. If for example the LIO code only creates a valid NAA/WWN 
> from a hex string of a certain length, it should only accept a hex 
> string of that length. It should not be a requirement to exactly follow 
> what rtslib does in every case.
> 
> Of course the way I see it the vendor specific identifier doesn't 
> necessarily have anything to do with the NAA/WWN, so it would be nice if 
> one could set both a WWN as a hex string of the correct length and 
> format, and a vendor-specific string in a mostly freeform manner as long 
> as it abides by SPC-3. The WWN shouldn't necessarily be generated from 
> the vendor identifier.
> 

As target emulation for 0x83 designators are both based on
vpd_unit_serial attribute to provide uniqueness, the current code allows
up 254 bytes supporting variable length designators exceeding what is
defined for individual NAA IEEE Registered fixed lengths and striping
off the remaining bytes.

The intention here is for the two EVPD 0x83 to contain similar enough
values based on vpd_unit_serial so they can be recognized as the same
LUN from both designators.  So the question is how should the kernel be
formatting input from a configfs attribute who's value is used to
produce freeform ASCII uniqueness for one case, and hex2bin safe
formatted uniqueness for another..?

So sing vpd_unit_serial for the vendor specific identifier area to
ensure uniqueness for the two EVPD 0x83 cases still makes sense to me,
but failing on non hex specific vpd_unit_serial input is likely too
restrictive for all cases.  Stripping of the hex characters from the NAA
IEEE registered vendor specific identifier area is an option for
userspace already using a properly formatted uuid, but this obviously
still requires filesytems who are aware of NAAs designators to update
their on-disk metadata when the '-' is stripped from the uuid ->
vpd_unit_serial input.

--nab