This article discusses the problem of file system corruption in raspberry PIs:
Over the years, we’ve used a number of rPIs here. Our younger children have used a rPI for their “personal computer.” The result was eventually always the same – eventual filesystem corruption in a matter of weeks or months of use. We also used to use rPIs for our home audio system running Kodi. The result was always the same – eventual file system corruption. We tried the official rPI power supplies, different models (rPI2, 3, 4), several different SD card brands, etc. Nothing seemed to make any real difference. Since then, I’ve used ODROID C2s in several applications (Kid’s computer, Kodi, and one industrial product) running from a SD card. So far, we’ve not had any problems. We’ve also used SD cards in custom industrial devices running Embedded Linux (SOM + baseboard), and they have been surprisingly reliable – even with 10,000+ units in the field.
All this is fairly hard to explain – especially considering the rPI organization is very successful. They certainly have the engineering resources to solve problems like this. But, they are also very committed to low cost, which they do very well. Perhaps a power supply architecture, PCB stack-up, etc that would be reliable is simply too expensive. One person noted:
Corrupted MicroSD cards have been a problem with my Pi3 since day one. I have never gotten that 3 to actually stay working for more than a few days at a time and it has defied all attempts to try different software. On the other hand, I have had beautiful results with multiple Pi Zero 2 W boards and I cannot think of any future for my Pi3 beyond smashing it to bits someday so nobody else ever has to fight with it.
It’s likely that the CM4 and other rPI products designed for industrial use are designed to be more robust, however I don’t have any real-word experience with them yet.
The rPI SBCs are great products and have contributed much to Embedded Linux development. They are great platforms for development and experimenting. However, you have to be aware of tradeoffs. What are you optimizing for?
The only times I’ve ever had an SD card go bad on me in my entire life was due to only 1 of 2 things:
I was trying to kill it to see how long it would last.
It was a cheap piece of junk Kingston brand card.
Kingston were easy to buy and I had a bunch of them but they’re not the only brand which were real crap, just the only brand I bought a bunch of which were real crap.
I’ve had no problem using Samsung Pro series micro SD cards in my Raspi 4 for a few months or in my Beaglebone Black for the past like 3 years (it’s my PiHole machine at home). In both cases, running normal Debian, not Raspbian, and never spending any time trying to limit flash writes at all.
A few jobs ago we had great luck with San Disk Ultra 4GB micro SD cards. Shipped a few hundred units with those. Then we switched to industrial rated cards as a precaution, but not because we were seeing failures.
From what I’ve read, some contribution of the electrical design of the earlier Raspberry Pi boards may have contributed to SD card failures but I suspect a lot of it is just people choosing SD cards based on misguided information.
I think a lot of this type of problem also stems from the “maker” culture. Not to say that “maker” culture is bad, but just that the subset of people who understand any given engineering problem out of the vast number of people who might experience it is a very small percentage. The chance that someone who actually can diagnose and fix any given “maker” problem actually getting listened to is fairly low, there’s a lot of noise in the maker community and not much signal.
It’s still great to be a maker! Just realize it’s a hobby and apply the scientific method to your problems rather than blindly trusting the things you read on the Internet.
Yeah, I’ve had great success as well shipping products with SD cards. rPI is the only platform I’ve had real problems with, but it was a statistically insignificant number and not a product, so we did not put any real engineering into it.
Kind of stuff I hack on requires changing complete OS frequently, so before I had Yoe updater working on rPI, I use to flash new OS on it often, sometime many times per day, but even since yoe updater has started to work on it, I do not recreate the card, but I do apply updates regularly, I have not seen the SD card go bad luckily, perhaps I am lucky, but then I do not have any products using rpi either, but its exercised quite heavily in tests on daily bases, all my rpi runs Yocto based distributions. I did have kodi OS on it few years ago, where it did get corrupted one time.
I had an original Raspberry Pi 1 with the full-size SD card slot on the back side of the PCB. It was notorious for having a poor connection with the SD card, and about once a year, it would no longer boot due to disk corruption. I considered hot glue at one point for the SD card slot… it was beyond awful.
Since those dark days, I have upgraded to a rPi 3 and a high-quality 512 GiB Micro SD card with high read/write speeds. I have yet to have a single problem with disk corruption, and we’ve experienced our fair share of power outages.
I also run another rPi 3 at the office with an older 64 GiB Micro SD card, and it runs noticeably slower, but I’ve never had corruption issues. Both rPis run as servers and see regular reads and writes. The office one powers our Gitea deployment.
Barring the bad SD connector on the original rPi (which many users reported), I think SD card corruption is more of a function of the SD card itself, not the rPi hardware. That’s my hunch based on very little anecdotal information.
Just as an aside, when working for Sweet Amanda’s we deployed hundreds of USB flash drives for vending machines. They ran in high temperature environments for years on end, and they needed to boot 99.9999% of the time. We found that there are three things you need to do to make this work: (1) make the rootfs read only unless you need to upgrade software, (2) regularly fsync() your data partition, especially after important writes; and (3) [VERY IMPORTANT] don’t buy cheap USB sticks.
I know this has little to do with SD cards and rPi, but I think it’s an important point to pay a little more for better flash memory products, especially since they are so affordable to start. Disk controller firmware is more important than folks realize, and since you can’t read this source code, you just need to buy from a vendor you trust to make good decisions.
@bminer thanks for the additional insight/experiences.
Lacking an engineering analysis as @bradfa suggested, I suspect one of the issues with the rPI may be “compatibility” as well as quality, because a number of our rPI setups over the years have used left-over Transcend industrial SD cards from a project, which had performed very well in 1000’s of devices. So I don’t think the SD card quality was lacking here, but perhaps something just did not mesh well with the rPI.
perhaps they should have used read only rootfs + overlayfs to reduce the chances of card failures