[PATCH 1/2] nvme: check duplicate unique identifiers in order

[John Meneghini]

On 7/22/25 7:58 AM, Martin K. Petersen wrote:
> 
> Hannes,
> 
>> If we now can get Oracle to chime in (maybe with a different patch
>> altogether?) we have all major vendors implementing different fixes
>> for the same problem.
> 
> We have posted our quirk patches on several occasions.
> 
> The challenge is how to work around duplicate identifiers while reducing
> the number of cases where /dev/disk/by-foo would end up changing. Either
> as a result of a firmware update or as a result of updating kernels.

Not sure that's possible because we can only control what the Kernel does.

If a firmware update is going to change, add, or remove an EUI64 or NGUID or UUID identifier
we can't fix that.  But we can enforce a uniform set of rules in the kernel that does the
correct thing based up the spec.
  
> The issue is pervasive enough that OCP has a defined EUI64 workaround in
> their SSD spec.

https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-6-2-pdf

Is this the specification you are referring to?

NVMe-CFG-7
The single default namespace (see SECTOR-3) shall have a unique non-zero value in the
EUI64 (Extended Unique Identifier) field in the Identify Namespace data structure.
For each namespace that is created other than the initial namespace configured in the
factory, the device shall clear the EUI64 field in the Identify Namespace data structure to 0h.

NVMe-CFG-8
The device shall support a non-zero NGUID per Namespace that is never reused (i.e., the
UIDREUSE bit in the Common Namespace Features field of the Identify Namespace data
structure shall be set to 1b).

/John