It came to my attention recently that many people don’t quite know what to look for in a micro-SD card for use in a Pi. As mercilessly torturing micro-SD cards is something of a hobby round here I thought I’d write a quick guide to what to look for.
A small selection of the SD cards that have graced my desk over the years, ranging from the rubbish to the really rather good.
Vegas Standard
There have been many standards for SD cards to conform to over the years, but the vast majority of them are concerned with sequential transfer rates. These started with the so-called speed classes, where Class 4 implied that a card could sustain a write speed of 4MB/sec to the card, Class 6 implied 6MB/sec and so on.
Later there were the UHS speed classes, where U1 was equivalent to the older Class-10, a sustained write speed of 10MB/sec to the card. U3 implied 30MB/s sustained write speed. Why a new class system? Because UHS also required a specific bus speed (confusingly designated UHS-I, then UHS-II, etc). Hence, a U1 card must manage 10MB/sec minimum but the corresponding bus speed could top out at 104MB/s allowing considerably faster read speeds (depending on bus compatibility).
Later still came the video speed classes. These still use the UHS bus interfaces, but demand higher minimum sequential write speeds. V10 requires 10MB/s minimum, V60 requires 60MB/s minimum and so on. Here’s a nice little table outlining the minimums required by each of these classes.
| Minimum write performance | Speed Class | UHS Speed Class | Video Speed Class |
|---|---|---|---|
| 2MB/s | — | — | |
| 4MB/s | — | — | |
| 6MB/s | — | ||
| 10MB/s | |||
| 30MB/s | 〃 | ||
| 60MB/s | 〃 | 〃 | |
| 90MB/s | 〃 | 〃 |
Got all that? Good. Now you can forget it.
As I mentioned above all of this is to do with sequential access. This is very useful in a camera where you’re recording video frame after video frame (or still image cameras that do … erm … exactly the same thing only much slower with considerably larger frames!). However, this doesn’t remotely resemble the access pattern of an operating system on an SD card which will typically entail hundreds of small writes to small files spread across a multitude of sectors.
In other words these classes will tell you next to nothing about the performance of your card in a Raspberry Pi. For that you need guarantees about the minimum random access performance. Luckily, the recent SD specifications have a standard for that too: the application performance classes.
Poker Face
At the time of writing, two application classes are defined: A1 which is fairly common on decent cards, and A2 which is still somewhat “premium”. Their minimum guarantees are as follows:
| Minimum read performance | Minimum write performance | Application class |
|---|---|---|
| 1500 IOPS | 500 IOPS | |
| 4000 IOPS | 2000 IOPS |
Note that these guarantee both write and read minimums. Further, they’re not concerned with bytes transferred, but with IOPS, or I/O operations per second. The exact meaning of IOPS is rather loose across storage generally but here it means the number of block sized (4KB) read or write commands that can be carried out per second. Even this is relatively fuzzy because the controller in an SD card is free to batch operations together. Erasure is almost always batched into “extents” of blocks, and writes can be generally too.
In addition to the above requirements, A1 and A2 both require a minimum of 10MB/s sequential write speed (equivalent to the old Class 10 cards). This may appear excessive. After all, if A1 only demands that a card handle 500x 4KB writes per second, that only equates to 2MB/s? However, remember that cards are free to batch operations together. Cards that do not conform to one of the application classes may well display 10MB/s sequential writes to one large file by batching together smaller writes that are all in sequence. However, if asked to perform many small 4KB/s writes to a multitude of blocks, the performance suddenly drops off a cliff.
In my experience, any reputable card with an A1 mark performs “well” on a Pi. A2 cards from a given vendor perform better than A1 cards from that same vendor, but I’ve also had A1 cards from vendor A beat A2 cards from vendor B. But when I say “beats”, I mean in performance benchmarks. I cannot say I ever noticed a difference in daily usage.
To put it another way: A1 is the sweet spot right now, and A2 is probably a waste of money at this point unless you’re quite sure you absolutely need the performance.
Shooting Craps
The astute reader may have noticed my careful use of the word “reputable” just before “card” in the prior section. Fakes are a problem, or have been in my experience (though we’re going back several years here).
Buy from well-known outlets, not minor vendors on whatever variant of flea-bay you frequent [1]. Just because it’s on Amazon, doesn’t mean it’s not a knock-off; check the actual seller.
Cheap, bulk deals are especially to be avoided. There’s enough competition in the micro-SD card market that there’s usually little that can be (legitimately) saved by buying in bulk; if the unit price is substantially below what you could get the individual cards for, be wary!
To summarize:
- Buy well-known brands,
- from reputable vendors,
- avoiding bulk (or suspiciously cheap) deals.
- Look for A1 or A2 on the casing [3]. Any modern card without those marks is likely to be rubbish for use in an SBC like a Raspberry Pi.
The Long Game
I haven’t had any issues for the last few years, but during them I’ve stuck to buying strictly from either SanDisk or Samsung (also had a Toshiba card that lasted many years without issue, but it’s a singleton sample), and avoiding any cheap-looking bulk deals.
This is not to say these cards last forever. But I have several Pis that run 24x7, and “good” cards seem quite capable of lasting at least 5 years in them, which is “good enough” for my purposes (I’ve had hard drives last less than that before!).
The failure modes of micro-SD cards seem to fall into two camps:
- completely dead — the card can be detected in a reader but fails to mount at all
- going “read-only” — the card will happily mount, and read pretty much anything but all writes are silently thrown away
The latter sounds preferable, and in some ways it is because if you have any data you want to recover from it, you can do so. But it’s also worse in certain circumstances.
Consider a board where the card “goes read-only”. It may appear to continue operating quite happily (if it’s serving a static site for instance), but all writes to logs are being thrown away. It’s also quite confusing to diagnose if you’re not specifically looking for it because the card may appear to be operating normally.
When dealing with a card I know to be old one of the first things I’ll try (assuming I can mount it at all), is touch foo, remove and re-mount the card, followed by ls just to see if an empty “foo” file shows up. If it doesn’t, the card’s almost certainly gone read-only and it’s time to make a fresh one.
| [1] | eBay, Amazon, Alibaba, whoever. If it’s a large marketplace, I’ve had fakes from it (certainly from the aforementioned big three). Ideally, buy from your local electronics vendor (Pimoroni [2] or The Pi Hut for me) but failing that, look for the larger vendors on the big marketplaces. |
| [2] | Unfortunately, at the time of writing, Pimoroni‘s SD card offering doesn’t include shots of the front of the card. Being a reputable company, I’d be extremely surprised if they weren’t good quality A1 cards, but it’d be nice to see this at least suggested visually! |
| [3] | Assuming you can make it out from the cacophany of logos. Is it just me, or are micro-SD card cases beginning to look like the side of a Formula 1 car? |