Hacker News Reader

Comment by mgamache | Hacker News Reader

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?

View on HN

I hear this every year when I post new benchmark results, but it's weird, I have literally not had one microSD card failure when using any of SanDisk, Samsung, or Sony.

I had one fail with a Toshiba card, but at that time I was also using a cheap micro USB power adapter that probably wasn't putting out a solid 2A.

I think the primary reason people have problems with microSD card corruption is the power supply. Even with a good power supply, when you plug in a lot of USB devices and push a Pi to the limits, it can draw ~2+ Amps, and only very good power supplies will not have weird issues at that draw.

The Pi doesn't handle that situation very well (nor do microSD cards).

But running my Pis headless (no USB accessories attached) without any video output keeps the power draw down to 1-1.5A max, even when CPUs are maxed out and I'm saturating the network.

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.

You can also get "Endurance" SD cards. A lot of failures are due to too many writes. The endurance ones allow many more writes than the regular consumer cards

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...

[2] https://www.cactus-tech.com/resources/blog/details/slc-pslc-...

That's blatantly not true, as I've run into controller issues from verified authentic name brand cards. A 80kbyte/sec write with a specific pattern for about six hours would absolutely hose the card (and yes the card was write leveling).

There's so much nice about the industrial cards that have nothing to do with it's ability to endure extreme environments, that I would basically never ship a non consumer product without them at this point.

> A 80kbyte/sec write with a specific pattern for about six hours would absolutely hose the card (and yes the card was write leveling).

80kB/s sounds a bit low for a card that is doing full "global" wear leveling; memory cards and SSDs that don't have DRAM often cut corners on the wear leveling, so they aren't as effective as proper mainstream SSDs. Your workload was probably issuing the writes in chunks smaller than the flash memory's page size (typically 16kB these days), so you probably had serious write amplification from the read-modify-write cycles even if that 80kB/s was sequential writes. SSDs with decent-sized write buffers and power loss protection capacitors can do more write combining than a memory card that has to be prepared for sudden power loss at any moment.

Yeah, it is very low, which is why I bring it up. It was a controller bug, where the FTL completely lost track of some sectors. Write amplification has nothing to do with it.

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

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

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

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.

I've had much better luck using aMLC and pSLC cards than generic TLC ones. I would expect "industrial" MLC/SLC to be even better. There was an enlightening discussion on HN about them at https://news.ycombinator.com/item?id=16776344

You can also reduce risks with your choice of filesystem, read-only partitions, and FS tuning/alignment. I wrote up my findings after looking into it last year: https://kevinlocke.name/bits/2018/04/28/rpi-sd-card-storage-...

really, what the pi needs is rpi-config to support an option for a read-only root filesystem with an overlay filesystem.

For example, this is the standard configuration for openwrt (which you can run on the pi)

That’s not a panacea. Power loss can still get you: https://news.ycombinator.com/item?id=16777889

Reply on news.ycombinator.com