Slow Reading m.2 NVME (single drive)


Hello from a new user trying TrueOS as a possible development desktop. Looks promising, but only if I can find a way to better utilize my Samsung 960 EVO m.2 NVME For a 1 Gig zeroes file using dd, results are:

Antergos ext4:
1000 MB/s to create
2000 MB/s to retrieve.

800 MB/s to create
260 MB/s to retrieve

This is a single drive installation with 4K forced (via advanced install checkbox), swap file disabled. No customization of partitions or anything else. Ryzen 3 1200 in an Asus Tuf Gaming B350 board with 8GB RAM.

Commands used to test:
dd if=/dev/zero bs=4096 count=1000000 of=file_1GB
dd if=file_1GB of=/dev/null bs=4096

I am running the TrueOS development branch, fully updated last night before running this test.

Thank you for any suggestions or explanations!


Repeat it thrice, to see the effects of caching (ARC), if there are any. Compare the timings.


I think this was a false alarm.

diskinfo -t reports transfer rates around 2GB/sec, which is within Samsung’s spec for sequential read.

I also see much higher results with dd using a larger bs parameter.

Thanks for your reply.


You need to be cautious about exactly what you are trying to measure. You’re test is measuring a single instance of filesystem throughput, not raw device speed. diskinfo may be giving closer to raw device speed.

nvme devices: take a look at the nvmecontrol command. Typically nvme devices have multiple work queues and you need to keep queues occupied in order to get the benefits. You wind up getting that with a larger bs parameter.


Thanks for those tips.

This was really just intended as a quick sanity verify that my nvme was not performing orders of magnitude below spec. I felt the need to investigate due to longer boot time times compared to Arch Linux (which I am gathering is probably an inherent design tradeoff).

In case it’s of any interest, I’m leaning toward OpenBSD+Xfce (with default ffs) as the best fit for my priorities. Running the original dd commands there yields the following results, regardless of bs parameter:

OpenBSD 6.2 ffs:
890 MB/s to create
975 MB/s to retrieve


And the OpenBSD Meltdown fix is released already, too. Last to get the info, first to deliver a fix.
Yea! OpenBSD! Go!


If you’re interested, give DragonflyBSD a whirl. It’s a fork of FreeBSD back around 5.x timeframe and Matt and others have been doing a lot of good work over there (yes, they have Meltdown and Spectre fixes). They have their own set of ports/packages, good info on installing and setting up X environments.