When an NVMe SSD is installed in a slot that supports fewer PCIe lanes than the drive itself, the model name alone cannot tell you the active link. The community thread used lspci to compare the device's PCIe capability with the link that was actually negotiated.
Check Link Capability and Current Link State
The compact command shared in the thread was:
sudo lspci -vv | grep -E 'PCI bridge|LnkCap|LnkSta'For a specific PCI device, it is usually easier to inspect that device directly once you know its bus address:
sudo lspci -s 05:00.0 -vvThe important fields are:
- LnkCap: the PCIe speed and width the endpoint or link is capable of advertising.
- LnkSta: the speed and lane width currently negotiated.
If a drive can operate at a wider link but LnkSta shows fewer lanes, the platform is currently running that device at the narrower negotiated width.
Map NVMe Names to PCIe Addresses
The original poster also found verbose nvme-cli output useful for matching Linux device names to controllers and PCIe addresses:
nvme list -vThat makes it easier to connect an entry such as /dev/nvme1 with the PCI address you inspect through lspci.
Link Speed Is Not the Same as Real SSD Throughput
LnkSta answers the PCIe negotiation question. It does not tell you the SSD's real sequential write speed, random IOPS, thermal throttling behavior, or sustained performance.
For actual I/O behavior, use an appropriate benchmark against disposable test data and define the workload carefully. The fio workload documentation explains why block size, queue depth, access pattern, I/O engine, and test size all change the result.
Do not run destructive raw-device benchmarks on a filesystem or disk that contains data you need.
Current PCIe and Benchmark Context
The Zima PCIe ecosystem is useful for understanding the difference between a physical slot and its actual electrical lane width. The PCIe expansion cards shows the kinds of NVMe and networking adapters used in Zima expansion projects, while the ZimaBoard 2 hardware provides a concrete current example of a platform where PCIe generation and lane count are explicitly specified.
The lspci device inspection defines lspci as the Linux utility for inspecting PCI buses and devices, while nvme-cli device listing shows how nvme list -v maps controllers, namespaces, transport, and PCIe addresses. For measured I/O rather than bus negotiation, use the fio workload documentation; queue depth, block size, read/write mix, and test size all change the result.
Bottom Line
Use lspci -vv to verify negotiated PCIe generation and lane width, and use nvme list -v to map NVMe devices to their PCIe addresses. Then benchmark separately if you need real storage throughput. A negotiated link rate is a bus property, not an SSD performance score.
