Today I published a video detailing my testing of three new Raspberry Pi HATs—these HATs all add on PoE+ power and an NVMe SSD slot, though the three go about it in different ways.
You can watch the video for the full story (embedded below), but in this post I'll go through my brief thoughts on all three, and link to a few other options coming on the market as well.
For years, SBCs that aren't Raspberry Pis experimented with eMMC and M.2 storage interfaces. While the Raspberry Pi went from full-size SD card in the first generation to microSD in every generation following (Compute Modules excluded), other vendors like Radxa, Orange Pi, Banana Pi, etc. have been all over the place.
Still, most of the time a fallback microSD card slot remains.
But microSD cards—even the fastest UHS-II/A2/V90/etc. ones that advertise hundreds of MB/sec—are laggards when it comes to any kind of SBC workflow.
The two main reasons they're used are cost and size. They're tiny, and they don't cost much, especially if you don't shell out for industrial-rated microSD cards.
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.
With the Raspberry Pi 5's exposed PCI Express connector comes many new possibilities—which I test and document in my Pi PCIe Database. Today's board is the Geekwork X1011, which puts four NVMe SSDs under a Raspberry Pi.
Unlike the Penta SATA HAT I tested last month, this carrier uses thinner and faster NVMe storage, making it a highly-compact storage expansion option, which has the added benefit of freeing up the top of the Pi 5 for other HAT expansion options.
In my video about the brand new Raspberry Pi 5, I mentioned the new external PCIe port makes it possible to boot the standard Pi 5 model B directly off NVMe storage—an option which is much faster and more reliable than standard microSD storage (even with industrial-rated cards!).
Enabling NVMe boot is pretty easy, you add a line to /boot/firmware/config.txt, modify the BOOT_ORDER in the bootloader configuration, and reboot!
Last year, after I started a search for a good out-of-the-box all-flash-storage setup for a video editing NAS, I floated the idea of an all-M.2 NVMe NAS to ASUSTOR. I am not the first person with the idea, nor is ASUSTOR the first prebuilt NAS company to build one (that honor goes QNAP, with their TBS-453DX).
But I do think the concept can be executed to suit different needs—like in my case, video editing over a 10 Gbps network with minimal latency for at least one concurrent user with multiple 4K streams and sometimes complex edits, without lower-bitrate transcoded media (e.g. ProRes RAW).
For many years, I've maintained some scripts to do basic disk benchmarking for SBCs, to test 1M and 4K sequential and random access speeds, since those are the two most relevant tests for the Linux workloads I run on my Pis.
I've been using this script for years, and it uses fio and iozone to get the metrics I need.
And from time to time, I would test a number of microSD cards on the Pi, or run tests on NVMe SSDs on the Pi, Rock 5 model B, or other SBCs. But my results were usually geared towards a single blog post or a video project.
In 2021 James Chambers set up PiBenchmarks to move to a more community-driven testing dataset.
You can run the following command on your SBC to test the boot storage and upload results directly to PiBenchmarks.com:
This is a simple guide, part of a series I'll call 'How-To Guide Without Ads'. In it, I'm going to document how I set up bcache on a Raspberry Pi, so I could use an SSD as a cache in front of a RAID array.
bcache is sometimes used on Linux devices to allow a more efficient SSD cache to run in front of a single or multiple slower hard drives—typically in a storage array.
In my case, I have three SATA hard drives: /dev/sda, /dev/sdb, and /dev/sdc. And I have one NVMe SSD: /dev/nvme0n1.
I created a RAID5 array with mdadm for the three hard drives, and had the raid device /dev/md0.
I then installed bcache-tools:
$ sudo apt-get install bcache-tools
And used make-bcache to create the backing and cache devices:
Late last year, an engineer at Broadcom sent me some hardware and offered some help getting Broadcom's MegaRAID card working on the Raspberry Pi. It took some time, but eventually we were able to get the card and a demonstrator 'UBM' backplane working on the Pi, and it culminated in my posting about Hardware RAID on the Pi, and on a livestream, getting 16 hard drives working on a Pi.
The one thing I couldn't test in those earlier videos was the backplane and storage card's 'Tri-mode' support, allowing PCI Express NVMe drives—like KIOXIA's CM6—to work in the same slot as the SATA and SAS drives I was used to testing.
So after some conversation with reps at KIOXIA, I was able to get a PM6 and three CM6 drives on loan to test them:
When the Compute Module 4 was released (see my CM4 review here), I asked the Pi Foundation engineers when we might be able to boot off NVMe storage, since it was trivially easy to use with the exposed PCIe x1 lane on the CM4 IO Board.
The initial response in October 2020 was "we'll see". Luckily, after more people started asking about it, beta support was added for direct NVMe boot just a couple weeks ago.
