We're using hundreds of raspberry's as digital signage devices and before deploying them I checked a few of them and found out that sometimes the source files of the app were empty.
After a lot of headscratching and googling we boiled it down to a write delay to the SD card.
If you do echo "test" > test.txt and power off the device like 5 sec. after, and power it on again, there was a file called test.txt with 0 bytes.
I'm still baffled how something like this can be a common problem especially since raspberry pi usage is so widespread
* The OS is is always read-only. While this doesn't prevent all possible corruption scenarios, it's pretty close and you can be quite sure the system always boots.
* System updates are implemented as A/B. So even during updates, the OS the system booted from isn't touched.
* All content data is on a third partition and together with the OS files is constantly checked for indications of corruption.
* If the OS detects any bit error on the OS files, it is reinstalled (using the A/B mechanism above)
* If there's a bit error on any of the content files, they are deleted and downloaded again
* If the content filesystem is broken beyond repair the system reformats everything and restores everything automatically by redownloading
* Various watchdogs and checks constantly monitor system health and notify you on the dashboard.
The service has multi-million hours of service by now and the only case of filesystem corruption was due to a really crappy SD card. When done properly, the Pi can be reliable. That's also the reason why there is no way to properly shut down the system. Just unplugging power shouldn't be an unexpected circumstance but something you optimize for. Starting with a normal Raspbian and expecting that to work is a bad idea.
It always looked to me like the Pi was supposed to be used some steps before hardware integration and shipping.
I am glad products are built on it but I was a bit worried when I had to evaluate a Pi based solution for digital signaling last year. Maintenance was a key factor in the proposals.
Most file system drivers delay writes, I suspect some variant of your test (if it was unsafe shutdown) could be reproduced on almost any system.
Also raspis do NOT like big fast SD cards with tight tolerances. I've had the best luck with old class 4 cards. Class 10 cards don't last nearly as long with regular power cycling.
The options are the third column in your /etc/fstab file. For example, if you had "errors=remount-ro", you'd change it to "errors=remount-ro,sync".
(Or is the Raspi problem actually in hardware?)
https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSyn...
Except that you don't need to buy an SD card. Or a special 2.5A power supply. And you can access the it solely over USB so you don't need to hook up an external keyboard, mouse, and HDMI to get it running headless. And you can actually get the chips and their datasheets for the BBB. etc.
But, hey, the RPi is half the price, man.
Mounting root read only and only writing explicitly through the "ro/re" scripts helps a lot and should be the default IMO.
The biggest issue some people have with RPis though, is their hackish software, e.g. the kernel. This has become better apparently, but it always was a shame that you couldn't just run a generic kernel/distro.
I had good experiences with the BeagleBoneBlack, they come with eMMC and quite a few smart additions (e.g. a power button). Twice as expensive though.