Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: 'nvme' command not working with new SSD (Read 2777 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

'nvme' command not working with new SSD

I just bought a Kingston NV3 2TB SSD and an m.2 enclosure for it.  It's plugged into my USB-C port (showing as /dev/sdb).  My laptop (System76 Galago Pro 5 - https://tech-docs.system76.com/models/galp5/README.html) currently has a WDC WDS100T2B0C 1TB SSD in it internally (for 4 years) and running 'sudo nvme list' shows:

Code: [Select]
$ sudo nvme list
Node                  Generic               SN                   Model                                    Namespace  Usage                      Format           FW Rev  
--------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- --------
/dev/nvme0n1          /dev/ng0n1            21244J802669         WDC WDS100T2B0C-00PXH0                   0x1          1.00  TB /   1.00  TB    512   B +  0 B   211210WD

The Kingston SSD *should* be showing above, but... well, that's a problem.

Code: [Select]
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model:  SNV3S2000G     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 33C68679-E7AE-4987-A7F8-1E52F207BF6F

Device          Start        End    Sectors  Size Type
/dev/sdb1        2048    1050623    1048576  512M EFI System
/dev/sdb2     1050624   63965183   62914560   30G Linux filesystem
/dev/sdb3    63965184 3898640383 3834675200  1.8T Linux filesystem
/dev/sdb4  3898640384 3907028991    8388608    4G Linux swap

I just created the above partition table, so the device seems to work ok (although i haven't created any filesystems on it yet).  I spent hours reading, trying to determine whether i should try to set the logical sector size to 2048 bytes and finally decided to try it.  First step recommended was usually to determine what LBA format the drive is currently using with "sudo lvme id-ns /dev/..."  If i do this on my internal drive, i get lots of output, with two lines for the LBA format (512 & 2048 bytes) at the very end.  Doing this with the Kingston drive yields:

Code: [Select]
$ sudo nvme id-ns -H /dev/sdb
get-namespace-id: Invalid argument

In fact, pretty much every 'nvme' command specifying this device yields roughly the same result, e.g.:
Code: [Select]
$ sudo nvme list-ns /dev/sda
id namespace list: Invalid argument

I've found zip searching online, although Yandex AI told me that the problem was *not* because my NVMe drive is plugged into a USB port.  I also tried plugging into a different (USB-A) port... no difference.

My reading indicated that consumer nvme drives might be limited in what 'nvme' commands (like creating a new namespace) will actually work.  But the basic things work fine with my internal drive, so... i don't believe that "unsupported LBA format" or "namespace issues" have anything to do with what is wrong.

As far as i can tell, so far, this problem isn't preventing me from using the SSD as is (512 byte logical sectors)
so nothing is stopping me from "cloning" my old EFI System partition, home and root partitions... except that
I've got another SSD coming in a few days (WD_BLACK 2TB SN850X).  I'm just playing around with this Kingston POS until that arrives.  If the WD Black doesn't have this problem then i'll know it was the Kingston drive.  But i'm 50/50 on whether i'll see the same thing with the new SSD, when i get it.

Also...

Code: [Select]
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 5986:9102 Acer, Inc BisonCam,NB Pro
Bus 003 Device 006: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 003 Device 022: ID 2109:2813 VIA Labs, Inc. VL813 Hub
Bus 003 Device 023: ID 2109:2813 VIA Labs, Inc. VL813 Hub
Bus 003 Device 031: ID 3938:1193 PixArt Onn OpticalMouse
Bus 003 Device 032: ID 308f:0015 Input Club Gemini Dawn/Dusk
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 003: ID 2109:0813 VIA Labs, Inc. VL813 Hub
Bus 004 Device 004: ID 2109:0813 VIA Labs, Inc. VL813 Hub
Bus 004 Device 012: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 M.2 NVME Adapter

I don't see anything, in the above, for the Kingston drive.  Seems like, normally, i should (it's plugged in and fdisk shows it), but i'm not certain.

As always, any insight is greatly appreciated.

Addendum: This is the output when i plugged the enclosure containing the Kingston SSD into the USB port
(after running "dmesg -W"):

Code: [Select]
$ dmesg -W
[888161.366843] usb 4-2: new SuperSpeed Plus Gen 2x1 USB device number 13 using xhci_hcd
[888161.395092] usb 4-2: New USB device found, idVendor=0bda, idProduct=9210, bcdDevice=20.01
[888161.395102] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[888161.395105] usb 4-2: Product: Ugreen Storage Device
[888161.395107] usb 4-2: Manufacturer: Ugreen
[888161.395110] usb 4-2: SerialNumber: 012938053179
[888161.427006] usb 4-2: Enable of device-initiated U1 failed.
[888161.427699] usb 4-2: Enable of device-initiated U2 failed.
[888161.457404] usb 4-2: Enable of device-initiated U1 failed.
[888161.458120] usb 4-2: Enable of device-initiated U2 failed.
[888161.461728] scsi host0: uas
[888161.907461] scsi 0:0:0:0: Direct-Access     KINGSTON  SNV3S2000G      1.00 PQ: 0 ANSI: 6
[888161.934545] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[888161.936205] sd 0:0:0:0: [sda] Write Protect is off
[888161.936212] sd 0:0:0:0: [sda] Mode Sense: 37 00 00 08
[888161.938747] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[888161.939919] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[888161.939925] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes
[888161.951302]  sda: sda1 sda2 sda3 sda4
[888161.951682] sd 0:0:0:0: [sda] Attached SCSI disk
[888192.556022] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN 
[888192.556033] sd 0:0:0:0: [sda] tag#10 CDB: Read(10) 28 00 e8 e0 86 20 00 00 d8 00
[888192.572570] scsi host0: uas_eh_device_reset_handler start
[888192.696709] usb 4-2: reset SuperSpeed Plus Gen 2x1 USB device number 13 using xhci_hcd
[888192.783108] usb 4-2: Enable of device-initiated U1 failed.
[888192.783693] usb 4-2: Enable of device-initiated U2 failed.
[888192.784504] scsi host0: uas_eh_device_reset_handler success

It's interesting to me that all the lines of output that relate to the SSD itself are prefaced by either "sd" or "scsi".
The lines relating to the enclosure seem to be the only ones prefaced by "usb".

Re: 'nvme' command not working with new SSD

Reply #1 –
It's normal. It's not nvme device (because you're not using pcie) anymore, you're essentially converted that literally to a standard usb flashdrive.

Re: 'nvme' command not working with new SSD

Reply #2 –
Thanks.  This possibility certainly occurred to me but in all my searching i was unable to find anything that said this.  So i assumed it wasn't the case.

Re: 'nvme' command not working with new SSD

Reply #3 –
As long as that enclosure treats your drive properly with HW trimming, essentially abstracting the fact that it's nvme ssd from you, that's even better, because you don't have to do it by yourself on linux. ;p
Also make sure you're getting close to advertised speeds with something like KDiskMark, it's available here (Imo, would be nice to have that in Artix repositories, as it's in Arch's extra <wink, wink to the Artix devs>): https://github.com/JonMagon/KDiskMark/releases/tag/3.2.0

Re: 'nvme' command not working with new SSD

Reply #4 –
I guess this is going a little off topic (not that i mind) but... i had no idea these NVMe enclosures were so... complex... at the time i bought mine.  But, subsequently, my research uncovered various chipsets in these things, the possibility of doing firmware upgrades...

I had no idea that HW trimming (whatever that is) might be something involving the enclosure.  I don't grasp that at all unless i'm misunderstanding your reference to "that's even better, because you don't have to do it by yourself on linux" being to using 'fstrim'.  With the latter, the O/S notifies the drive about unused blocks.  How having the drive in an enclosure rather than plugged into a PCIe slot would allow the enclosure to do "trimming"...  If i can make any sense of this at all it would be that this is not making up for some functionality lacking as a result of being plugged into the enclosure => USB, rather than NVMe => PCIe, but that it is added functionality.  Yet that still makes no sense, as the enclosure can't know about O/S blocks.  So HW trimming must be something completely different and i must have misunderstood what i could only understand as a reference to 'fstrim'.

Anyway, this focus on enclosures maybe illuminates something else that i looked up but was unable to find anything useful about... except for... "it's nothing, don't worry about it."  Which is the log errors i see for my drive when i plug it in, specifically:

Code: [Select]
...usb 4-2: Enable of device-initiated U1 failed.
...usb 4-2: Enable of device-initiated U2 failed.

Now, i'm thinking that these occur *because* it's in an enclosure that doesn't allow certain functionality that would be available if plugged directly into the PCIe bus.

Re: 'nvme' command not working with new SSD

Reply #5 –
Quote from: craigduncan – on
I had no idea that HW trimming (whatever that is) might be something involving the enclosure.  I don't grasp that at all unless i'm misunderstanding your reference to "that's even better, because you don't have to do it by yourself on linux" being to using 'fstrim'.  With the latter, the O/S notifies the drive about unused blocks.  How having the drive in an enclosure rather than plugged into a PCIe slot would allow the enclosure to do "trimming"...  If i can make any sense of this at all it would be that this is not making up for some functionality lacking as a result of being plugged into the enclosure => USB, rather than NVMe => PCIe, but that it is added functionality.  Yet that still makes no sense, as the enclosure can't know about O/S blocks.  So HW trimming must be something completely different and i must have misunderstood what i could only understand as a reference to 'fstrim'.
Think about it carefully, you're essentially putting a "converter-type device" that changes the way the NVMe drive operates. The system talks to this enclosure, and the enclosure keeps track of and abstracts a lot of the PCIe/NVMe protocol communications. Who knows exactly what else it could? Certainly I don't. I'm just assuming that if that enclosure costs a lot of money, then the manufacturer of such a device at least did the absolute minimum by providing and integrating the essential trimming functionality. Since, again, this device abstracts a complicated NVMe drive into a glorified thumbstick when it's just plain USB 3.0, hence why I advised checking the advertised speeds.

The situation would be different if this was USB3.2 gen2/thunderbolt/USB4 enclosure (+ you'd use this on a motherboard that supports those), because when those are involved then the proper PCIe passthrough mode is possible and then your nvme drive would be enumerated exactly as /dev/nvme0n1 or something similar... Then you'd just use it the way you had initially thought it would work out.

It's exactly why I added: As long as that enclosure treats your drive properly with HW trimming, essentially abstracting the fact that it's nvme ssd from you, that's even better, because you don't have to do it by yourself on linux. because if you take a look here for example regarding trimming when using such enclosures, it isn't exactly a streightforward matter:
https://discussion.fedoraproject.org/t/enabling-trim-discard-on-external-ssd/154211
https://askubuntu.com/questions/262154/trim-and-ssd-with-usb-3-0-enclosure-does-not-work-uasp-not-supported
https://bbs.archlinux.org/viewtopic.php?id=244636
Quote from: craigduncan – on
Now, i'm thinking that these occur *because* it's in an enclosure that doesn't allow certain functionality that would be available if plugged directly into the PCIe bus.
Yep, it's exactly as you say.

Re: 'nvme' command not working with new SSD

Reply #6 –
Don't try and do anything low level to any ssd / nvme connected via usb. You can brick the drive.

https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing
https://archive.kernel.org/oldwiki/ata.wiki.kernel.org/index.php/ATA_Secure_Erase.html
https://forum.artixlinux.org/index.php/topic,7824.msg46969.html#msg46969

Re: 'nvme' command not working with new SSD

Reply #7 –
Nvme in an external case might get hot, a well as in a thin mobile notebook and I would not advise that.

Hot nvme might get throttled down automatically, maybe.

Kingston Nvmes had some problems in the past, because the energy managment that is coded into the nvme firmware was not optimized and though was only working well on Windows machines.

nvme are so extremly fast, that it might be a bad idea to combine that with USB3.

Generally, I would prefer SSD over nvme, even those are slower.



Re: 'nvme' command not working with new SSD

Reply #8 –
Quote from: yoyo55 – on
Nvme in an external case might get hot, a well as in a thin mobile notebook and I would not advise that.
Hot nvme might get throttled down automatically, maybe.
Kingston Nvmes had some problems in the past, because the energy managment that is coded into the nvme firmware was not optimized and though was only working well on Windows machines.
nvme are so extremly fast, that it might be a bad idea to combine that with USB3.
Generally, I would prefer SSD over nvme, even those are slower.
Nope, I don't agree with that, even 2015-esque NVMe drives won't reach full bandwidth with basic USB3.0 enclosure, so the drive won't be even as stressed as with native protocol. With modern pcie4.0/5.0 nvmes you'll only get those 4-5 Gigabyte/s speeds with thunderbolt/usb4.

Re: 'nvme' command not working with new SSD

Reply #9 –
Let us agree on: I don´t know for sure.
Latency USB3:  30 microseconds
Latency Nvme: 2 milliseconds

Do what you think is right and do not listen to people who claim that they are not 100% sure.
Or maybe you should, I don´t know.