To add a little more information, the reason for the "NO" votes was as follows: If a storage device implements this TODAY - and the only unique identifier in VPD page 0x83 is the UUID identifier, then, any existing shipping host will not find any unique identifier that it recognizes. That host could do any number of other things (including but not limited to): 1) prevent the device from being used; 2) enable only a SINGLE path to the device (do not allow MPIO to operate on a device for which it cannot find a unique ID); 3) enable MPIO to the device using the unique ID of "NONE". Both 1 & 2 are workable situations. BUT, #3 is a problem; not if you have just 1 of these UUID only devices, but if you have a bunch of them, and the host incorrectly assumes they are all the SAME device, and it tries to do IO based on that assumption. So that is the background. The "NO" votes were based on the belief by those companies that situation #3 was a forgone conclusion, and they didn't want to add any new features to the storage until after the hosts added code to support those new features - which the hosts can't do until there are storage devices built (based on a standard) which they can use for testing - CATCH-22. The "YES" votes were based on the assumption that storage would not be configured with ONLY the UUID value unless the storage manager knew that the host to which it would be connected could actually support a UUID only storage system. A configuration of a UUID only storage and a host that does not support UUID only storage is a configuration error. No different than a "thin provisioned" LUN being configured for use by a host that prohibits the use of thin provisioned LUNs. Basically it is assumed that initial deployments of UUID identifiers would be in conjunction with other (NAA/EUI/etc) identifiers in page 0x83). Remember, real H/W vendors already own NAA and EUI values. The primary creator of the UUID form will be S/W defined storage LUNs (as indicated in the preface material in the proposal), where there is no NAA or EUI available. It simply goes back to the catch-22 - which comes first, the host support or the storage device support. The solution is expected to show up in the next revision of the standard - there will be a temporary editor's note added indicating something along the lines of: a UUID only VPD page 0x83 should not be implemented in a storage device until it is known that the host supports such a configuration. That note will be removed before final ANSI/ISO publication, but it will remain during the draft cycle. At least, that is where the discussion ended up last I knew - we'll find out at the next meeting. There was some minor discussion about that lack of uniqueness guarantees, but basically the committee said, you get what you get, and if you don't like it, don't use it. You can also see, that the data structure is already primed for the addition of the 32 byte UUID value (if/when anyone ever invents such a beast, we'll examine whether it too should be added). So I hope that clarifies some of the background around the controversy. Fred Knight -----Original Message----- From: Douglas Gilbert [mailto:dgilbert@xxxxxxxxxxxx] Sent: Monday, February 08, 2016 3:04 PM To: James Bottomley; SCSI development list Cc: Knight, Frederick Subject: Re: T10 adds locally assigned UUID designation descriptor On 16-02-08 02:00 PM, James Bottomley wrote: > On Mon, 2016-02-08 at 12:33 -0500, Douglas Gilbert wrote: >> Recently, in draft spc5r08, T10 added a locally assigned RFC 4122 >> UUID *** designation descriptor. That descriptor can now be >> returned for VPD page 0x83 (device identification) amongst others. >> It can be used anywhere SCSI needs a unique identifier expanding >> the previous set of preferred identifiers: EUI, NAA and SCSI_name >> (iSCSI). >> >> In the soon to be released sg3_utils version 1.42 the new UUID >> designation descriptor is decoded including Hannes' --export >> option found in sg_inq, for example: >> >> # sg_inq --export /dev/sg0 >> ... >> SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeffffee >> >> Perhaps some udev work is needed to incorporate this new identifier. > > Hm, we're going to have to do this carefully. With the move to GPT > partitions, both the UUID= designator in fstab and the /dev/disk/by > -uuid/ of udev means the GPT UUID. In theory the design of the UUID > space is to allow random selection without clashing, so we could just > place the SCSI ones in here as well and perhaps there won't be a > problem, but I'd like us to think about the consequences first. The UUID proposal (16-005r1 from Fred Knight and "Dr. Hannes Reinecke") was somewhat controversial with five T10 members voting against it. The minutes state: "The members voting no stated concern that this proposal may result in market confusion, and those members intend to develop proposals to mitigate any confusion." Locally assigned identifiers are not new: there already is an 8 byte locally assigned NAA identifier (NAA=3). It is not much used, perhaps the new locally assigned UUID (which is 16 bytes long) will find more use. As for the 'sg_inq --export' naming, that seems to nail down the context of the new UUID pretty well: SCSI_IDENT_[TARGET|PORT|LUN]_UUID with the identifier itself in canonical UUID format. So there should be no confusion there. And partitions are nested inside logical units and SCSI does not define those (apart from on tapes). Doug Gilbert ��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
