Hacker News Reader

Comment by johnnycab | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com