I've had numerous failures on older RPi models due to SD card corruption, even in non-write intensive contexts. Not sure this is good enough when you want reliability...
Basically, don't do continuous writing to the card, turn off atime updates,possibly even work entirely from the initrd if possible. Also, use proper industrial sd cards, these have proper wear-levelling and bad-block management unlike the consumer cards.
In other words, treat it as an embedded system and tailor it to your use-case.
That sounds interesting re. turning off atime updates, how do you do that out of interest?
Mount with -o noatime. The default (-o relatime) should however be good enough for most situations.
I've found that the only working recipe for a stable Raspberry Pi is a USB hard drive (prefer SSD but mechanical also fine), and a UPS.
My simple advice is: do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale, as you will run into filesystem corruption and create a lot of work for yourself.
1: https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/... 2: https://github.com/fhunleth/fwup
https://en.wikipedia.org/wiki/Multi-level_cell#Single-level_...
Example suppliers:
https://www.micron.com/products/nand-flash/slc-nand
https://www.cactus-tech.com/resources/blog/details/why-slc-s...
http://www.macronix.com/en-us/products/NAND-Flash/SLC-NAND-F...
https://business.toshiba-memory.com/en-us/product/memory/slc...
Or maybe this is just over-engineered, and maybe someone makes a pi that uses an SSD by default.
Is that true even if you mount the filesystem(s) read-only after boot time ?
As an aside, I have to say that it is very surprising and annoying how fragile "modern" drive parts are compared to decades ago when we were using either disk-on-chip or just plain old CF cards pin-compatible with the IDE connector.
I had 16MB CF cards on the IDE bus that lasted 15+ years[1] in production without a hiccup, but in 2018 SATA SSDs die randomly from time to time ...
[1] Yes, they were all mounted read-only ...
Those old parts used SLC (single bit per cell) flash, which has orders of magnitude higher endurance than whats used now, MLC or TLC (2 and 3 bits per cell). QLC (4 bit per cell) is starting to hit the market now.
Yes, read-only filesystems are not the solution to most of the Micro SD card problems on the Pi, because the filesystem and the OS are relying on the card to work properly, and the actual consumer market Micro SD cards people are using don't always do that when used in the Pi.
To manage the flash, the (dirt cheap, barely fit for purpose) controller inside a consumer Micro SD card will generally do things like move data from one area of flash to another, even when the host isn't writing to the card.
One of the reasons for that, is that reading from NAND is a potentially disruptive[1] event:
> If reading continually from one cell, that cell will not fail but rather one of the surrounding cells on a subsequent read. To avoid the read disturb problem the flash controller will typically count the total number of reads to a block since the last erase. When the count exceeds a target limit, the affected block is copied over to a new block, erased, then released to the block pool.
There are industrial Micro SD cards that can handle most of the problems that show up on the Pi though, and they aren't absurdly expensive. The $15 ATP AF4-GUD3A and $28 ATP AF8-GUD3A are some I use in my Pi projects for this reason, and I've never seen any of them become corrupt, unlike SanDisk and other consumer cards.
Can't confirm. I've written about this before, but I'm mainly responsible for running the https://info-beamer.com digital signage service. It's using a custom Linux distribution that always boots into an R/O system. All user content is on a separate partition that can always be restored if there's any error. The ext4 fs is tuned in a way that the kernel defers writes quite a while to minimize write access if possible. Since customers purchase their own SD cards, we have limited control of what ends up in a device. I've seen exactly one SD card related problem thus far. There are devices that have been running >3 years 24/7, so it's doable. But you can't just use Raspbian. You have to properly design the system.