
Raspberry Pi microSD card performance comparison - geerlingguy
https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-card-performance-comparison-2019
======
dmm
I wouldn't buy an sd card on amazon because of the risk of getting a fake.
There are tons of fake sd cards out there and amazon refuses to take
responsibility for their supply chain.

~~~
bradenb
I'm sure there's a name for this effect, but I am always fascinated by the
complaints about fake products on Amazon. I have _never_ received one and I
spend several thousand on Amazon every year.

I _know_ it must be happening, I just can't understand if I'm lucky, if it's
an effect of my location, or somehow related to the way in which I shop on
Amazon.

~~~
geerlingguy
Many of the major product listings seem to be okay—for example I've ordered a
number of the Samsung Evo+ cards I link to in the blog post, and tested each
one and never found one that didn't perform as the first I bought—but I have
gotten fakes here and there.

Almost every time, though, it's because the Amazon official supplier/warehouse
was out of stock and I accidentally ordered from one of the secondary
suppliers. The problem is, unless you know what to look for in the interface,
it's hard to determine if you're buying from Amazon or the manufacturer, or
some 3rd party.

Even then, there are many reputable 3rd parties. But there are many who are
not.

The worst cases in my experience are ordering 'Apple OEM' type products. I
will not buy a charger or any other Apple accessory on Amazon because more
than 50% of the time I've gotten a non-Apple-manufactured product.

~~~
ilikepi
> The problem is, unless you know what to look for in the interface, it's hard
> to determine if you're buying from Amazon or the manufacturer, or some 3rd
> party.

Also, Amazon sometimes commingles their own stock with that of 3rd-party
vendors, so "Ships and Sold by Amazon" doesn't mean what it used to.

EDIT: fixed numerous typos >:(

------
k_sze
I wonder if Pi 4 supports UASP (USB Attached SCSI Protocol). This may need
everything from the VLI VL805-06 USB controller to the firmware to the driver
to support it. A preliminary DDG search suggests that the controller probably
supports it.

My understanding is that, if UASP is supported, you can squeeze even more
performance out of a SSD, and it will even properly support the TRIM command
because then the SSD is no longer just a dumb USB mass storage device.

~~~
bonzini
TRIM is supported by USB mass storage devices since those are _also_ SCSI. It
is the bridges that may not support it, and the same is true for USB-attached
SCSI.

For USB-attached SCSI, what makes a difference in performance is support for
USB 3.0 streams, which allow multiple transfers to occur concurrently
([https://www.kernel.org/doc/html/latest/driver-
api/usb/bulk-s...](https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-
streams.html)).

~~~
k_sze
Ah. I didn't know that USB mass storage is also SCSI. Is TRIM/UNMAP part of
the SCSI Transparent Command Set, which depends on the SCSI Peripheral Device
Type reported (by the USB-SATA bridge?) in response to INQUIRY?

What exactly is the "SCSI Transparent Command Set" anyway? I haven't been able
to find an answer from DuckDuckGo search. The Wikipedia article on USB Mass
Storage [1] mentions it, but doesn't really define it. Neither does the
article on the SCSI command [2] itself.

Another post [3] touches upon SCSI Transparent Command Set, but also says in
passing that the SCSI specifications at t10.org don't mention the "SCSI
Transparent Command Set".

[1]
[https://en.wikipedia.org/wiki/USB_mass_storage_device_class#...](https://en.wikipedia.org/wiki/USB_mass_storage_device_class#Device_access)

[2]
[https://en.wikipedia.org/wiki/SCSI_command](https://en.wikipedia.org/wiki/SCSI_command)

[3]
[http://janaxelson.com/mass_storage_faq.htm](http://janaxelson.com/mass_storage_faq.htm)

------
gjsman-1000
Note to readers: The USB chip does run hot. This is getting fixed in a
firmware update that you can test in the RPF Forum which reduces temps.

~~~
gambiting
I wonder if that's the reason for somewhat patchy USB performance. when
copying data between two USB HDDs the data goes at 40-50MB/s for a minute or
two then drops down to like 500kb/s and then ramps up again after a while.
When copying data the USB chip and the ports themselves get stupidly hot.

~~~
geerlingguy
Yeah... it surprised me that the VLI USB chip was much hotter than the
processor even during CPU stress testing. Between that and the little power
controller chip by the USB-C power supply port, the Pi 4 pretty much demands
active cooling for any but the most mundane tasks.

------
brandmeyer
Once upon a time, Linaro produced flashbench, a tool for learning more
information about how managed NAND devices (mmc, sdcard, etc) actually manage
their flash. LWN did a story on some of their conclusions [1]. One of the
standouts for me was that some erase blocks are managed completely differently
from others, such that random i/o performance can vary based on the location
on the device. Traditional filesystem benchmarks aren't set up to observe this
behavior.

IIUC, F2FS incorporated some of that information, and not much else has. But
in principle, you should manage your device with short extents and inode
tables in the small-block-friendly area, and larger extents elsewhere whenever
possible.

[0]:
[https://github.com/bradfa/flashbench](https://github.com/bradfa/flashbench)
[1]: [https://lwn.net/Articles/428584/](https://lwn.net/Articles/428584/)

------
LeoPanthera
I now only use "Endurance" microSD cards, which I think are supposed to be for
dashcams, in my Pi's, because I've never not had a normal microSD card
ultimately be killed by the Pi through what I assume is write endurance
exhaustion.

~~~
kup0
Did they die pretty early on? Do you use USB port on a hub/PC/etc for power?

If answers to both of those questions are YES, over the years in reading
forums/comments/etc a common thread between them has been that rPi kills
microSD cards, and the commonality between _most_ of those posts has been the
use of (low/unstable) power strictly off of a USB port of another device
(instead of a wall adapter)

Edit: I now see that geerlingguy addresses this elsewhere in the thread too,
so he can add at least some anecedotal experience that drawing too much power
from a poorly-powered rPi is a recipe for failed SD cards

(Sorry if this is completely irrelevant- it may just be that if you write to
your cards a lot they're dying from that due to endurance, like you said)

~~~
LeoPanthera
I generally use a dedicated USB power supply so that should not be the
problem. And I haven't yet had an "endurance" card die.

------
beezle
Not Pi, but related - I gave up on using a 64GB Kingston SDXC in a Lexar
reader to play MP3s in my truck. After just a few days it would develop
corruption at the end of songs and by a few weeks it was just too annoying to
continue using.

I looked at some of the files and it appeared to be a bit flip type problem.
Went to a dedicated usb thumbdrive (as has been in my car's glovebox for 7
years) and no issues. Really makes me question using these sdxc cards at all.

------
mgamache
I know embedded systems were not the original purpose of the Raspberry Pi, but
so many people are trying to use the pi for just that. I've wanted to use Rpi
for that _but_ the SD card failure rates are high. I know the high-end ones
are a lot lower, but is it reliable enough? I am not sure. I was hopping for a
SD card alternative for the Rpi 4, maybe it's booting from USB 3.0 when that
ships?

~~~
orev
You can get “industrial” SD cards that are rated for more severe environmental
conditions and more write cycles. They are more expensive though, but probably
worth it for commercial applications.

~~~
johnnycab
The 'industrial' microSD cards based on MLC or pSLC with controlled or frozen
BoM only make sense if you are going to use a device in extreme settings[1].
In most instances, a card in rPi will serve as a boot device, unless someone
reappropriates it into a Dashcam or something similar, which has heavy duty
write cycles or continuously reads/writes to and from the card; it will be
wise to choose something that strikes a balance.

At a guess, the Samsung EVO family of consumer based cards, probably ranges
between using TLC (older) to 2D or 3D V-NAND (newer). The more robust Pro
series, which commands a premium, probably uses MLC or superior.[2]

[1] [https://www.swissbit.com/products/nand-flash-
products/micros...](https://www.swissbit.com/products/nand-flash-
products/microsd-memory-cards/)

[2] [https://www.cactus-tech.com/resources/blog/details/slc-
pslc-...](https://www.cactus-tech.com/resources/blog/details/slc-pslc-mlc-and-
tlc-differences-does-your-flash-storage-ssd-make-the-grade/)

~~~
Scramblejams
Well you’d better add “unexpected power loss” to your “extreme settings”
category. Loads of cards have problems with that. I’ve experienced multiple SD
card corruption events upon power loss with the Rpi until I started buying
industrial cards.

Had good luck with the ones mentioned in
[https://news.ycombinator.com/item?id=16777238](https://news.ycombinator.com/item?id=16777238)

~~~
johnnycab
It would not be feasible to list every extreme event or permutations thereof,
but any kind of power loss would be an undesirable event. Perhaps, it is not
clear from my comment, I added a caveat to distinguish between hobbyist or
commercial use i.e. in majority of former cases, it _might_ be feasible to
find a compromise between price, stability and endurance [0][1].

Further to your link, my experience with Samsung Pro series has been very
favourable. YMMV.

[0]
[https://www.raspberrypi.org/forums/viewtopic.php?t=184696](https://www.raspberrypi.org/forums/viewtopic.php?t=184696)

[1] [https://www.tomshardware.co.uk/raspberry-pi-4-ssd-
test,news-...](https://www.tomshardware.co.uk/raspberry-pi-4-ssd-
test,news-61094.html)

~~~
Scramblejams
It happens a lot, unfortunately, for multiple reasons. First is ordinary power
loss, then the fact that Rpi comes with no power button so people get
impatient and yank the power (ok, that’s not unexpected, but corruption is),
and then Rpis have long been known to be finicky with their power
requirements. In the latter case, I've seen it happen from a too-long USB
power cable.

One can argue about whether those reasons are in the "but the user should know
better" column, but when they result in a corrupted filesystem, they
nevertheless add up to a poor user experience.

Hope one day the Rpi has easygoing power requirements and a button you can
push for orderly shutdown.

------
chayesfss
My first time creating s pihole I had everything setup with a nice sd card
then proceeded to put this plastic case over it. Seemed a little tough to put
on like it was a little pressure fit so I clicked it into place then tried
starting it back up. Well it never came up then I started looking at the pi
and realized that the case didn’t have a cutout where the sd card protrudes
and it cracked the damn card at the tip! Ended up using a cheaper one I had
lying around but wow, lesson learned the hard way.

------
dev_dull
I'm a big fan of the RPI, and use them in various home projects, but I'm going
to continue to wait out the RPI updates until I can get a proper m.2 slot for
a "real" hard drive. Working with SD -- especially when continually
developing, is just too slow and painful. Not to mention questions about
lifetime and lifecycle.

The price of m.2 drives have come down so significantly that I think SD should
be slowly phased out, or added as a secondary option.

~~~
m463
There are a few ways to do this now:

m.2 add-on boards, such as
[https://amzn.com/B01NH2W8NL](https://amzn.com/B01NH2W8NL)

boot directly from a good usb flash drive (I like the sandisk cz80, though
they seem scarce now)

------
derefr
Is there really a need for random 4K writes on the SD card in the Pi? Couldn’t
the card use a log-structured filesystem and batch writes in RAM, turning
those writes into streaming writes? The new Pi certainly has enough RAM that
it could dedicate some to serving as a write cache.

~~~
pjc50
This is the choice that lots of system designers have to make, "low apparent
write latency" vs "maximum data at risk of power loss". If there's a database
on the Pi you're going to be upset if you call fsync() and it doesn't actually
do the writes.

~~~
hedora
This is a false dichotomy. Most (all?) contemporary high-reliability (and,
arguably, high performance) filesystems are long structured.

(I am excluding things such as ext4 that are missing data block checksumming,
and recovery from disk failure using parity stripes)

~~~
gruez
>high-reliability (and, arguably, high performance) filesystems are long
structured.

That prevents the filesystem from being in a inconsistent state, but doesn't
address the issue of data loss. eg. what happens if there's 5M outstanding
writes and you get a fysnc? If you wait for everything to be flushed, that's
going to produce latency. If you lie and return immediately, and there's a
power outage, you now lost those oustanding writes.

~~~
hedora
A decent FS will make sure there are never 5M outstanding writes that an
unrelated fsync depends on.

------
geerlingguy
tl;dr: the Pi 4 has a much more rosy outlook when it comes to IO both for the
microSD card and external drives. The Samsung Evo+ is still the best value for
your money.

~~~
meatmanek
I'm surprised by the lack of mention of the A1/A2 "Application Performance
Class"[1]. These classes specify minimum performance numbers for random reads
and random writes: 1500/500 read/write for A1, 4000/2000 read/write for A2.

Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not
the A2 version[2]

    
    
      1. https://www.sdcard.org/developers/overview/application/index.html
      2. https://smile.amazon.com/gp/product/B07FCMBLV6

~~~
jack12
My understanding is that A2 cards are generally slower than A1 cards IF you
don't have host-side support for managing the volatile-RAM caching that A2
requires.

So if the Pi 4 only allows you to run in A1 mode anyway, you're better off
buying the A1 card and both saving money and getting a faster card. I don't
know if that lack of support is true of the Pi 4, but it does seem to be true
of most other SBCs according to
[https://github.com/ThomasKaiser/Knowledge/blob/master/articl...](https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)

~~~
meatmanek
Ah, interesting, I did not realize there was a difference in protocol. I
thought A1/A2 were just spec requirements.

I wonder if A2 support is something that could be added in newer kernels, or
whether it requires hardware support.

