Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080 <me@alancui.cc>]

On Monday, 11 May 2026 16:16，Christoph Hellwig wrote：
> [the patch seem to be missing some maintainer Ccs]

Sorry, I've resent it.

> On Mon, May 11, 2026 at 01:19:59AM +0300, Sagi Grimberg wrote:
> > TBH, I'm not sure why should this be a warning or an info log. This looks
> > like a debug print to me.
> 
> It is worse.  For some reason the commit seems to imply the uuid
> replaces the nguid and they can be intermixed.

Which you refer to?

If it's my patch, My patch is actually intended to fix the issue where
"the kernel uses dev_warn_once, thus only reporting warnings for the
first block or drive where this problem occurs". So the key is "This
asymmetry can be misleading to users. If all devices in the system report 
the same issue, it might not be a problem, but if only one device reports it, 
it might (especially since I have two identical drives). ".

Futher more, should it be reported as a warning? The answer is No:
According to the NVM-Express-1_4 specification p.175 Figure 251:
"Bit 9 (UUID List): ...", UUID is not mandatory. And for devices below
spec revision 1.3, there is no UUID yet.

And yes?? Because according to NVMe 1.4 spec 7.10.6 UUID:
> The Universally Unique Identifier is defined in RFC4122 and con-
> tained in the Namespace Identification Descriptor
Current way how kernel generate UUID by NGUID is not compliant with RFC 4122
and NVMe spec. 
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/uuid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/nguid 
00000000-0000-0000-a428-xxxxxxxxxxxx

> We really need separate sysfs files for the different ids.  I gues we
> need to keep the existing one someone, but it is a mess.

I don't really know how and why user needs this UUID, because kernel said:

/* For backward compatibility expose the NGUID to userspace if
 * we have no UUID set
 */ 

[alan@AlanArchDesktop ~]$ ls /sys/block/nvme0n1/uuid (NVMe 1.4)
/sys/block/nvme0n1/uuid
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/uuid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/nguid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ ls /sys/block/nvme2n1/uuid (NVMe 1.3)
ls: cannot access '/sys/block/nvme2n1/uuid': No such file or directory
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme2n1/nguid 
cat: /sys/block/nvme2n1/nguid: No such file or directory
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme2n1/uuid 
cat: /sys/block/nvme2n1/uuid: No such file or directory

If it's mandatory for userspace, why the nvme2n1 has not, if it's not
mandatory, why should we create the UUID sysfd attr. then put NGUID in it?
But for a NVMe 1.3 device there is both no UUID and no NGUID, while kernel
is not reporting warnings at all?

The NVMe 1.4 spec Figure. 253 said:
> If the namespace does not support an IEEE Extended Unigue ldentifier
> (i.e., EUI64 field is cleared to 0h) and does not support a Namespace
> Globally Unigue ldentifier (i.e., the NGUID field is cleared to Oh), then
> the namespace shall report a Namespace ldentification Descriptor with
> a value of type 3h.

So it's really a optional parameter right?

Alan