Thanks for doing all that testing! Nice to see that answer pretty much boils down to "Use something decent-ish, mostly it doesn't matter which choice you make"... (I would have guessed nVME would have been worth spending extra on, turns out not by enough to care about, at least not in a Pi4.)

Yeah the Pi 4's USB 3.0 bus isn't able to take advantage of the speeds faster drives can put out; I'm hoping the next compute module can support NVMe or SATA more directly (something Eben Upton hinted at in a podcast earlier this summer). A Pi 4 B+ or Pi 5 could even fit a slot underneath?

I'd expect the compute flavour to expose the PCIe bus, so SATA or NVMe would be easily added as no USB3 chip hogging it. Indeed I'd say that is not only a given avenue, but the angle Mr Upton was hinting towards given the I/O side of things currently from the SOC.

Like many - pre Pi4, was wishing for a SATA port, but overall, if they did do some upgrade to the Pi4 in another B+ or 5 flavour - then I'd be more interested in a faster USB flavour, like 3.2 or USB-C. Reason being is that it would be more flexible and those who want SATA or NVMe would be able to tap into that. Certainly more flexible in usage and that does seem to be key.

Yes, I'm also anxiously waiting for the CM4, but wouldn't M.2, NVMe, & etc. be located on the carrier boards, instead of the Computer Module?

In hindsight, how would you have used the documentation of the Raspberry Pi architecture to determine whether UASP is supported?

Also, I'm really curious if your only problem with that Arcanite was only that it was a defective unit. If anyone reading has any other ideas for diagnosing that problem then I'd love to know them.

Great guide, Jeff. Really enjoyable (and informative!).

> In hindsight, how would you have used the documentation of the Raspberry Pi architecture to determine whether UASP is supported?

Doesn't really depend on the Pi hardware at all, it depends on the kernel driver (kernel must be new enough) and the USB storage device (does it implement UASP in addition to legacy bulk-only-transport?).

https://www.devever.net/~hl/usbuas has a great explanation of the nitty-gritty details.

Do you mean the Arcanite flash drive literally let the smoke out or did it just stop working?

Not likely to be smoke. However TRIM failures were very common with SSDs early on and even today some distros disable or partially disable it by default (see for example this Debian warning: https://wiki.debian.org/SSDOptimization#WARNING). Upstream Linux does not enable TRIM for MD-raid devices unless you use a special kernel boot parameter. "Continuous TRIM" (which means setting the discard parameter on the filesystem so that files are automatically trimmed on deletion) is also a good way to reveal bugs and problems, some of which will merely kill performance when you delete files, and others will nuke your data.

No smoke, just stopped working entirely, and can't mount it or partition it at all. Closest I can get is with Disk Utility on the Mac, if I partition it, it acts like it's working, then it gives an error on the last block of the device, something like that.

it would be interesting to see some NVMe benchmarks for the Pi 4, both enclosure and drive

I've got you covered, at least for an XPG NVMe in a TDBT enclosure: https://www.jeffgeerling.com/blog/2020/fastest-usb-storage-o...