I've recently been debugging some NVMe / PCIe bus errors on a Raspberry Pi, and I wanted a quick way to test NVMe devices without needing to create a filesystem and use a tool like iozone. I don't care about benchmarks, I just want to quickly push the drive and read and write some data to it.
fio is the tool for the job, and after a quick install sudo apt install -y fio, I create a configuration file named nvme-read.fio:
[global]
name=nvme-seq-read
time_based
ramp_time=5
runtime=30
readwrite=read
bs=256k
ioengine=libaio
direct=1
numjobs=1
iodepth=32
group_reporting=1
[nvme0]
filename=/dev/nvme0n1
Then run it with:
sudo fio nvme-read.fio
Easy way to put some stress on the drive, and test your PCIe setup and the drive itself.
Comments
You should write data first. For most drives, when you attempt a read on an LBA that has never been written it will automatically send zeros back instead of doing a NAND read which is effectively a controller/FTL test instead of a drive test.
Since Jeff mentioned him 'debugging some NVMe / PCIe bus errors' the type of data passing the bus is not of any interested to him. Though a test pattern that involves only reads (just like hdparm would've done it in the past) ignores the fact that there are PCIe TX and RX data lines.
Contact issues with some pins inside a connector might not get detected by such a mostly unidirectional test as such I second the suggestion to do some writes too :)
This particular test is just to hit the drive and make sure the bus is working at all—it was easy to identify weird issues with ASPM running this test with various configurations.
Well, I'd also add as a courtesy to readers, to point out at least the /dev/nvme?n1 as source. Sure, people shouild double check but you might always get someone wanting to test a disk in USE so hence a partition. No harm down in being a bit pre-emptive kiddo.
Talking about pre-emptiveness and reading. I broke my glasses yesterday; I shall use it as an excuse for reading(pun intended) this as a read write :p