Hacker News Reader

Comment by jrockway | Hacker News Reader

The reason why rPi uses micro SD is that it's the cheapest possible storage solution. You are not buying an industrial-grade workstation for $35. (For those using the rPi in industrial settings, there is the Compute Module which has eMMC. It adds to the cost, though.)

I am not really a fan of "embedded" devices that have to be shut down properly. You can never assume that you won't lose power, and I think there are a lot of flaky/bricked rPis as a result of SD not handing power loss well. But it's cheap, and you just reimage the thing and go when your SD card gets corrupted.

When I last worked on embedded Linux, our OS image was read-only and the writable storage was literally initialized at boot with "mount /dev/mmc1 /storage || mkfs.ext4 /dev/mmc1". That is how you get a consistent state after power loss. But throwing everything away at boot doesn't fit the Raspberry Pi model of being half-embedded half-workstation. The result is flakiness.

View on HN

> I am not really a fan of "embedded" devices that have to be shut down properly.

the problem is the Pi is not an embedded device, per se.

It's running a desktop operating system that has to be shut down properly. This is the main reason SD cards get corrupted - there is an unchecked flow of writes to the SD card. This increases the chance of outstanding unsynchronized writes and SD card burnout.

I've said many times that raspi-config should allow an option for mounting the filesystems read-only, with an overlay ram based filesystem.

You can run openwrt on the pi, and the filesystem is set up this way. I run a pi like this and have never seen a corruption problem.

>>I've said many times that raspi-config should allow an option for mounting the filesystems read-only, with an overlay ram based filesystem.

I've had success with this:

http://wiki.psuter.ch/doku.php?id=solve_raspbian_sd_card_cor...

yes this was my problem, as well as they actual SD card itself and the SD card slot going out sometimes from frequent rewriting

> SD not handing power loss well

Is it that SD cards themselves don't "handle power loss well", or is it bad assumptions made by the filesystems chosen to be used on them? Could a filesystem with a specific design avoid SD card corruption?

Partial out-of-order writes can happen with an SD card. Most filesystems do not handle partial writes well, particularly when they happen out-of-order. A redundant checksumming filesystem like ZFS might be better, but that's only because ZFS can totally handle up to N drives per vdev going totally batshit (where N is configurable when setting up the vdev), not because it is designed for SD cards.

Spinning drives can also have misdirected writes, but enterprise drives have for decades now (older than SATA) supported commands for flushing their caches, so proper barriers can be maintained.

My limited understanding from reading articles on the topic is that the SD card is doing things like wear leveling in a way that the OS can't control, so if it loses power while it's doing that, your data is gone. It's like a separate computer, and the integrity of your data requires running the program to completion.

It seems like a bad model if you ask me, but performance is what reviewers publish, not reliability under failing power, so this is what we get. It is obviously possible to fully journal these internal operations and recover them when power is next available (resulting in FS-level errors, instead of internal errors). But the cards do not do this.

With eMMC, you just have the raw flash cells available directly, so you can write this code. With SD, you don't have enough control to write correct code, so you are stuck with what the vendor gives you.

Why does this same problem never occur with USB flash drives? Is it just that a USB device is usually large enough to have room for some power capacitors?

USB is also designed so that data disconnects before power.

I'm not sure if that's enough by itself.

Not if the device loses power, right? I'm guessing USB flash drives will have the same internal mechanisms as SD cards and thus suffer from the same problems.

Oh, are you talking about flash drives used as system drives on a Pi? Because in desktop use power rarely goes out and even more rarely has anything been written recently. In the Pi use case I have no idea.

I have had 2 USB flash drives fail, one definitely after being unexpectedly disconnected (about the other one I don't know).

Thank you for bringing my attention to the rPi Compute Module, I hadn't known this existed.

That's why I recommended oDroid to people who want to regularly use systems like rPi's. Most of their offerings support eMMC add-ons

If you were to describe and prioritize issues I have with SD cards, "not handling power loss well" would not make my list. Silently dropping writes while fully powered is more like it.

Would a battery acting as UPS help then? One used just to power the system long enough to properly shut down in case of main power failure?

You don't even need a battery; even a 220uF capacitor gives you a couple of milliseconds at USB power levels[0].

0: USB is supposed to draw < 0.5A @ 5VDC, a resistance of >10Ω. 1F*1Ω=1s, so at 10Ω, each 100uF gets you one millisecond. You do need to worry about voltage dropping off over time though.

eMMC is not at all better then SD card though. You really need a real SSD for industrial applications.

It really depends, I think. If you are accessing the eMMC at the lowest hardware level, then you can write OS/filesystem-level code to maintain consistency when power is lost. Meanwhile, an SSD, like the SD card, is doing a bunch of internal operations that the OS can't control, so it's up to the hardware to maintain data integrity. I imagine that SSDs include a capacitor large enough to finish housekeeping, or use integrity-preserving operations internally (journal, etc.), but micro SD cards don't.

There's a lot more to preserving eMMC than just handling power losses.

A lot of what proper SSDs is to do the right wear leveling to make sure that damaged flash blocks don't cause corruption. eMMC is a pretty broad term that can cover something that's just a soldered SD card to something with a full-blown wear leveling controller.

That's why you still see a lot of eMMC failures in embedded systems when someone forgets to not log to the persistent storage or similar wear heavy operations.

Thanks for the tip. I was wondering about an easy way to boot like this. Better than nothing.

Reply on news.ycombinator.com