For most workstations and gaming PCs, what decides how an NVMe SSD feels is random 4K latency at low queue depth, write speed after the SLC cache fills, DRAM or a sound HMB design, and cooling, not the peak sequential figure on the box. PCIe 5.0 pays off only when a workload streams large files and the drive sits in a CPU-attached x4 slot. Servers add two requirements: endurance stated in DWPD and power loss protection. The sections below show how to check each point with fio, smartctl, and nvme-cli.
Sequential throughput versus random 4K at low queue depth
Sequential ratings are measured with large blocks and deep queues. They describe copying a video, restoring a disk image, or loading model weights. Compiling code, starting applications, and querying a database larger than RAM issue small reads instead, and each thread usually waits for one read before it issues the next. The drive then sees a queue depth of one to a few commands.
At queue depth 1, IOPS equals one second divided by the average latency. A 4 KiB read that takes 80 microseconds gives 12,500 IOPS, about 51 MB/s per thread. Halving the latency doubles that figure, while doubling the PCIe bandwidth changes nothing. That is why drives with very different sequential numbers can feel the same on a desktop.
Look for random 4K read and write results at QD1 and for p99 or p99.9 latency under a mixed load, and measure what vendors omit with the fio jobs below. Servers also need high-queue-depth IOPS, because many clients create real parallelism. An HNSW index that does not fit in RAM, as in the pgvector hybrid search guide, turns each query into dependent random reads, where tail latency matters more than GB/s.
PCIe generation, lane count, and M.2 slot wiring
PCIe 3.0, 4.0, and 5.0 run at 8, 16, and 32 GT/s per lane with 128b/130b encoding. The ceiling per direction is GT/s × 128/130 ÷ 8 GB/s per lane, so an x4 link peaks near 3.9, 7.9, and 15.8 GB/s before protocol overhead. A drive and a slot negotiate the highest generation and width both support: a PCIe 5.0 drive runs at 4.0 speed in a 4.0 slot, and an x4 drive in an x2 slot gets half the lanes.
On desktop boards some M.2 slots use CPU lanes and others hang off the chipset. The chipset has a single uplink to the CPU, shared by USB, SATA, networking, and every other chipset slot. Boards also share lanes, so filling one M.2 slot can disable SATA ports or drop the graphics slot to x8. The block diagram or slot table in the motherboard manual shows the wiring. Read it before you buy.
Put the system disk and the busiest project or database in a CPU-attached slot, and use chipset slots for games and archives. PCIe 5.0 is worth it for high-bitrate video, dataset copies, and loading large model files, as covered in the local LLM hardware guide. For gaming and general development, a good PCIe 4.0 drive with low QD1 latency is usually the better choice.
Check the negotiated link
Compare the current link with the maximum in sysfs:
cd /sys/class/nvme/nvme0/device
cat current_link_speed current_link_width max_link_speed max_link_width
A PCIe 4.0 x4 drive in a matching slot reports 16.0 GT/s PCIe and a width of 4. A lower value points to the slot wiring, a generation forced in firmware setup, a riser, or lane sharing.
Controller, DRAM cache, and HMB
The controller maps logical addresses to NAND pages through the flash translation layer. A flat map with a 4-byte entry per 4 KiB page needs 1/1024 of the capacity, which is the arithmetic behind the common ratio of about 1 GB of DRAM per 1 TB of NAND. A drive with DRAM keeps much of that map next to the controller, so random reads across a large span stay fast.
DRAM-less drives use the Host Memory Buffer (HMB) and borrow system RAM for part of the map. The drive requests a size in the hmpre field of Identify Controller, in 4 KiB units, and Linux caps it with nvme.max_host_mem_size_mb, 128 MiB per controller by default. HMB suits desktop patterns that touch a limited part of the drive. It helps less when random I/O spans hundreds of gigabytes, as with databases and VM images.
nvme id-ctrl /dev/nvme0 | grep -E '^(mn|fr|hmpre|hmmin|vwc|wctemp|cctemp) '
cat /sys/module/nvme/parameters/max_host_mem_size_mb
A non-zero hmpre on a drive without DRAM confirms HMB support. The buffer is small, but if system memory is already tight, the DDR5 memory guide helps with sizing.
TLC, QLC, and the SLC cache
TLC stores three bits per cell and QLC stores four. More bits per cell mean more capacity per die, but slower programming and fewer program/erase cycles. Client drives hide the slow programming with an SLC cache: incoming data is written at one bit per cell and folded into TLC or QLC later.
The cache is finite and often dynamic, so it shrinks as the drive fills. Once a long write exhausts it, speed falls to the post-cache rate, which tends to be lower on QLC. The Ceph hardware recommendations call this cliffing and warn that sustained performance can decline considerably after a limited cache fills.
Look for the cache size at a given fill level and the post-cache write speed in reviews or datasheets. If you often write tens of gigabytes at once, such as video ingest, VM images, or backups, choose TLC and keep free space. QLC suits read-mostly libraries: games, media, and model files.
Endurance: TBW, DWPD, and the warranty
TBW is the endurance rating from JEDEC JESD218: the decimal terabytes a host may write under the workload of the drive's class while the drive keeps its capacity, error rate, failure rate, and power-off retention requirements. DWPD states the same budget per day of the warranty:
DWPD = TBW / (capacity_TB × 365 × warranty_years)
TBW = DWPD × capacity_TB × 365 × warranty_years
A hypothetical 2 TB drive rated for 1,200 TBW over five years gives 1200 / (2 × 365 × 5), about 0.33 DWPD. A desktop that writes 50 GB a day uses about 91 TB in five years. A database that rewrites the whole drive daily needs more, and Ceph suggests 1 DWPD or more for demanding pools.
Host writes are not NAND writes. Small random writes, a full drive, and missing TRIM raise the write amplification factor (WAF). A worked example in the JEDEC material estimates TBW < (capacity × NAND P/E cycles) / (2 × WAF). Keep free space, enable TRIM, and buy more capacity for write-heavy work.
Many consumer warranties end at the time limit or at the rated TBW, whichever comes first. JESD218 also sets power-off retention at rated endurance: one year at 30 °C for client drives and three months at 40 °C for enterprise drives. An unpowered SSD is not an archive, so follow the 3-2-1 backup guide.
Thermals, throttling, and heatsinks
Each controller publishes two thresholds in Identify Controller. At WCTEMP it keeps working, but it needs more cooling or less load. At CCTEMP it may throttle hard, shut down, or lose data. The NVM Express Base Specification 2.4 defines these temperatures in kelvins and recommends a warning threshold of 343 K, about 70 °C.
PCIe 5.0 drives and fast PCIe 4.0 drives generally need a heatsink under sustained load. Use one, either the board's M.2 cover with its thermal pad or the drive's own, and make sure airflow crosses it. In laptops and small cases, a lower-power drive can sustain more work than a faster one that throttles. The SMART log counts minutes spent at or above each threshold. If the warning counter grows during normal work, improve the cooling.
Power loss protection and enterprise drives
Client drives acknowledge writes held in a volatile buffer and rely on the host to flush them before power disappears. The SMART log counts sudden power cuts as Unexpected Power Losses, a field earlier specification revisions called Unsafe Shutdowns, and the specification warns that data corruption may occur on drives not protected against power loss.
Enterprise drives with power loss protection (PLP) use capacitors to write buffered data and metadata to NAND after power drops. Acknowledged writes survive, and flushes complete without waiting for NAND. Software that calls fsync constantly, such as databases, write-ahead logs, ZFS intent logs, and Ceph, therefore runs faster and more predictably, and Ceph recommends enterprise drives with PLP.
nvme id-ctrl /dev/nvme0 | grep -E '^vwc '
cat /sys/block/nvme0n1/queue/write_cache
The vwc field shows whether the controller reports a volatile write cache, and write back in write_cache means Linux sends flushes to the drive. The datasheet is the authority on PLP. Never disable flushes or filesystem barriers on a client drive to improve benchmark numbers.
Test a new drive with fio
Test before the drive holds data, and use files on its filesystem, because writing to a raw device such as /dev/nvme0n1 destroys its contents. The jobs use direct I/O and io_uring. Use --ioengine=libaio on older kernels. fio lays out the test file first, so reads hit written data.
cd /mnt/newdrive
# Random 4K reads at queue depth 1: what a desktop feels
fio --name=qd1-randread --filename=fio.test --size=32G \
--ioengine=io_uring --direct=1 --rw=randread --bs=4k \
--iodepth=1 --time_based --runtime=60 --ramp_time=5 \
--lat_percentiles=1 --percentile_list=50:99:99.9
# Mixed random 4K with parallelism: closer to a busy server
fio --name=qd32-randrw --filename=fio.test --size=32G \
--ioengine=io_uring --direct=1 --rw=randrw --rwmixread=70 --bs=4k \
--iodepth=32 --numjobs=4 --group_reporting --time_based --runtime=120
# Sequential write past the SLC cache, bandwidth logged once per second
fio --name=seqwrite-cliff --filename=fio-big.test --size=300G \
--ioengine=io_uring --direct=1 --rw=write --bs=1M --iodepth=8 \
--write_bw_log=cliff --log_avg_msec=1000
For the QD1 job, read the average and p99 latency, not only IOPS. For the mixed job, compare p99.9 latency between drives. Size the cliff job above the expected cache and below the free space. It writes cliff_bw.1.log, one line per second with the time in milliseconds and the bandwidth in KiB/s, and a plot shows the cached rate, the cliff, and any throttling. Delete the test files afterwards. The fio documentation describes every option.
Read health with smartctl and nvme-cli
smartmontools and nvme-cli read the same SMART / Health Information log:
smartctl -x /dev/nvme0
nvme smart-log /dev/nvme0
nvme-cli 3.0, released in September 2026, renames commands to forms such as nvme log smart and nvme id ctrl. The hyphenated names used here remain as deprecated aliases and also work with nvme-cli 2.x.
- Critical Warning: any non-zero bit needs action. The bits cover spare capacity, temperature, reliability, and read-only media.
- Available Spare: remaining spare capacity. A fall toward Available Spare Threshold means the drive is retiring blocks.
- Percentage Used: the vendor's endurance estimate. It can exceed 100, which alone does not mean failure.
- Data Units Written: thousands of 512-byte units. Multiply by 512,000 to get bytes, so 10,000,000 units are 5.12 TB. Track it monthly to learn your real DWPD.
- Media and Data Integrity Errors: unrecovered errors. Any increase means you should verify backups now.
Self-tests and firmware
smartctl -t short /dev/nvme0
smartctl -l selftest /dev/nvme0
nvme fw-log /dev/nvme0
fwupdmgr get-updates
fwupdmgr update
Device self-test is optional in the NVMe specification, so some drives reject it. Let smartd or your monitoring system alert on the fields above. Firmware changes performance, power management, and error handling, so read the release notes and back up before an update. The fwupd NVMe plugin installs updates from vendors that publish to LVFS and activates them at the next reboot. Other vendors need their own tool, or nvme fw-download and nvme fw-commit with their image. Update one drive of a mirror first. If a drive drops off the bus under Linux, look for a firmware fix; the kernel parameter nvme_core.default_ps_max_latency_us=0 disables autonomous power state transitions as a diagnostic step.
Partition alignment and TRIM on Linux
fdisk and parted align partitions to the I/O topology the device reports, so keep their defaults and verify the result:
lsblk -t /dev/nvme0n1
parted /dev/nvme0n1 align-check optimal 1
nvme id-ns -H /dev/nvme0n1 | grep 'LBA Format'
The parted align-check command reports whether partition 1 is optimally aligned. The last command lists the supported LBA formats and marks the active one. Many drives ship with 512-byte sectors and also offer 4096-byte sectors. nvme format --lbaf=<n> switches formats but erases the namespace, so decide before storing data and after checking that the boot loader, RAID layer, and hypervisor handle 4Kn devices.
TRIM tells the drive which blocks are free, so garbage collection skips stale pages, write amplification falls, and post-cache speed holds up. Prefer periodic trim:
sudo systemctl enable --now fstrim.timer
sudo fstrim -av
lsblk --discard
The fstrim manual calls weekly trimming sufficient for most desktops and servers and warns that frequent trimming or the discard mount option might shorten the life of poor-quality SSDs. Btrfs has enabled discard=async automatically on capable devices since kernel 6.2. Non-zero DISC-GRAN and DISC-MAX values in lsblk --discard mean discards reach the device. dm-crypt ignores discards by default because they can reveal which blocks are in use. Enable them with the discard option in crypttab or with --allow-discards only if that leak is acceptable. Keep free space as well, since the SLC cache and garbage collection both need free blocks.
Matching the drive to the build
| Requirement | Gaming PC | Developer or creator workstation | Database or VM server | Read-mostly bulk storage |
|---|---|---|---|---|
| Interface | PCIe 4.0, 5.0 optional | PCIe 4.0, or 5.0 in a CPU slot | U.2, E1.S, E3.S, or M.2 22110 | PCIe 4.0 or 3.0, chipset slot |
| Random 4K at QD1 | High | High | High, plus high-QD IOPS and p99.9 | Low |
| DRAM or HMB | HMB acceptable | DRAM preferred | DRAM | HMB acceptable |
| NAND | TLC, QLC for a game library | TLC | Enterprise TLC | QLC acceptable |
| Post-cache writes | Low | High | Steady-state rating | Low unless ingest is large |
| Endurance | 0.3 DWPD is ample | Calculate from your writes | 1 DWPD or more | Low |
| Power loss protection | Not needed | Useful for local databases | Required | Not needed |
| Cooling | Board heatsink | Heatsink and airflow | Chassis airflow | Board heatsink |
Checklist before and after purchase
- Describe the workload: daily writes, largest single write, access pattern, and fsync-heavy software.
- Check in the board manual which M.2 slots are CPU-attached and what they disable.
- Use TLC with DRAM for heavy random or write work, and HMB or QLC for read-mostly roles.
- Calculate DWPD from TBW and read the warranty terms.
- For servers, require PLP, a DWPD rating, and a firmware update path.
- Fit one heatsink with airflow and check the temperature counters after a week.
- After installation, confirm link speed and width and record the firmware version.
- Run the three fio jobs and keep the results as a baseline.
- Enable
fstrim.timer, check alignment, and settle the LBA format before storing data. - Monitor Critical Warning, media errors, Available Spare, and Percentage Used, and keep backups on other media.