Tales of Raspberry Pi SD card corruption are available online by the fistful, and are definitely a constant in Pi-adjacent communities. It’s apparent that some kind of problems tend to arise when a Raspberry Pi meets an SD card – which sounds quite ironic, since an SD card is the official and recommended way of booting a Pi. What is up with all of that?
I can start with a history lesson. Back when Raspberry Pi launched in 2012 – which is now 10 years ago – there were SD card controller driver problems, which makes sense given the wide variety of SD cards available out there. They were verifiably fixed one by one at some point in time, as debugging goes, their impact decreased and bugs with individual cards got smoothed over. This is how the “Pi SD card corruption” meme was originally born; however, if the problems were to end there, so would the meme. Yet, tales of broken SD cards plague us to this day – way less severe than they were in the beginning, but pronounced enough that you’ll see people encounter them every now and then.
Over the years, a devoted base of Pi SD card haters has grown. Their demand has been simple – Raspberry Pi has to get an ability to boot from something else, in large part because of corruption reasons, but also undeniably because of speed and capacity/cost limitations of SD cards. Thanks to their demands and work, we’ve seen a series of projects grow from unofficial efforts and hacks into officially supported Raspberry Pi abilities – USB boot being initially more of a workaround but now something you can enable out of the box, SSD-equipped Pi enclosures becoming more of a norm, and now, NVMe boot appearing on the horizon. Every few years, we get a new way to boot a Pi.
Should You Ditch SD Cards?
I’d like to make it clear – booting from an SSD or USB drive is a very nice option, and when you want your Pi to be fast, responsive, and reliable, you can absolutely try it. The SD card slot has stayed after all this time, is not about to disappear, and neither will all the SD cards in our drawers. Should you personally ditch SD cards? The answer is more likely to be “no” than “yes”.
Not everyone encounters SD card problems, with SD card images being the first thing available whenever you see a cool new project, and an SD-equipped Pi still a staple of an average maker contraption. Proponents of USB and network boot also cite improved latency for Pi-as-desktop usage, easier Pi management in case of network boot, and these alone are good reasons – but definitely not for every project out there. SD cards remain the simplest and cheapest option to boot a Pi.
You cannot always avoid SD card boot either. Booting a Pi Zero from an USB stick requires that you either waste your only USB port or add an entire USB hub into the mix, complicating the setup further, adding pesky cables and failure points. When it comes to portable and battery-powered devices built with a Pi, an SD card is hard to beat in terms of power consumption – USB flash drives aren’t known for being low-power-optimized, and neither are USB hubs, which you’ll notice if you check how warm a USB hub IC can get after passing a relatively low amount of USB packets.
In the end, even the most devoted external SSD booting enthusiasts might still want to add an SD card for the independent additional storage that it brings. The slot is there, and if you have a card to spare – why not use it? Unless you encounter problems, that is – so let’s go through those.
Why Do Cards Still Fail?
First of all, fake and cheap cards ruin the fun for everyone. MicroSD card clones are ever-present and hard to distinguish from legitimately made cards, but certainly not subject to the same quality standards. Cheap cards share the “low quality standards” part, but at least, you can recognize a no-name card by looking at it. Neither fake nor cheap cards are typically suitable for an entire OS to run from. They will not only make your Pi behave way more sluggishly than it actually can run, but will also result in mysterious failures and, later on, pretty explicit corruption. Getting decent cards from reputable places is part of a recipe for a calm Pi exploration journey, and nowadays, it doesn’t even really break the bank anymore, given the hefty amount of storage that you get for your money.
Even genuine cards can cause trouble. Our hackerspace bought a batch of genuine Samsung cards for our Pis back in 2014, and every single one of them has eventually died with the same symptoms – since every Pi used a card from the same batch, it ended up with hackerspace infrastructure dying out device-by-device, frustrating the members relying on it. After all, an SD card is a complex highly-integrated device, with the controller being a small purpose-built CPU – there’s room for firmware errors, manufacturing defects, and just good old hardware randomness. Supposedly, we are past this, but be wary.
It Is Now Safe To Turn Off Your SBC
Like majority of storage devices nowadays, an SD card has two separate entities inside – controller and flash memory. The controller has some flash management busywork to do whenever it gets sent some data to write, but doing it on the spot would be time-consuming, delaying subsequent write operations, and possibly wasteful. Subsequently, the SD card controller has to have a small piece of cache memory, and keep a list of operations that are yet to be performed but haven’t been.
This is the rationale behind “shutting down your Pi safely” aka “running poweroff before unplugging power” talking point – if you don’t give your SD card a bit of time and maybe even an automated advance notification from the OS, there might be pending write operations that will never get completed, resulting in garbled storage when you next power up the card. Some seasoned engineers claim that such shutdowns are eventually guaranteed to irreversibly break an average SD card long-term, due to how the cards work internally, and I wouldn’t argue with them on that.
Can you rely on an SD card even if unsafe shutdowns happen every now and then? My experience says “yes”. One of my first “engineering” role jobs was testing a Pi-based commercial device for exactly this problem, where I’ve built a test setup powering down a Pi during SD card writes and ran it for a few days, with our software still passing all the tests. To my knowledge, we shipped that hardware combination successfully long-term. With ZeroPhone, unconventional power management without a software counterpart to compensate for its shortcomings led to regular (sometimes even cyclical) brownouts every few days during a span of few years, whenever I’d forget to charge it. The SD cards I used survived quite well long-term and live to this day, save for an uneventful fsck every now and then.
My conclusion is that, while safe powerdowns are desired, being lax is not the end of the world, and many a hobbyist who has yanked the power cable out of their Pi carelessly will confirm this experience. However, if your software does a considerable amount of writing to the same SD card you run your OS from, perhaps you’d like to offload it somewhere else.
Don’t Cheap Out On Your PSU Either
There’s an unusual suspect to be mentioned, and that is power supply quality. Sometimes mentioned offhand, it’s an underappreciated reason, and I’ve had a years-long corruption-plagued hackerspace Pi debugging quest where that turned out to be the culprit. The Pi in question was the only one from an entire Pi network to get these issues, and was also powered by a hand-soldered LM2576 SMPS without a ground plane in sight – obviously the only viable solution at the time of build, which stayed there for ages because of the “hey, it works” human factor.
While the DC-DC doesn’t power the SD card directly — there’s a 5 V to 3.3 V regulator onboard for that — every single part of that setup, from the Pi to the filesystem, was replaced. Pis can be current-hungry, especially if they’re powering other USB devices. Thin cables and underspec supplies can lead to brownouts, and the poor SD cards pay the price.
Swapping the DC-DC to a regular blue “LM2596” module, reinforced with extra capacitors and thicker wires, was the solution that actually made the corruption problems disappear. There might be a lesson about noise propagation somewhere in there. For you, the conclusion I recommend, based on this and other similar but less puzzling experiences, is – obey the Ohm’s law in spirit, and make sure the path for juices to flow to your Pi isn’t constricted by an awfully thin and long MicroUSB or Type-C cable, or a DC-DC setup that turns out to be subpar.
New And Underappreciated Helpers
Nifty tricks appeared over the years that, if suitable for your use-case, will give you extra anti-corruption protection and undoubtedly provide some peace of mind. One such thing is the OverlayFS option in Raspbian, a small menu entry in raspi-config that was added sometime in 2019. If you enable it and reboot, your Pi will behave the same, but none of the changes you make will actually get written to your SD card – which also means they won’t get saved and will disappear after your reboot. If you want to change files on your SD card, you’ll want to disable OverlayFS, reboot, make the changes, re-enable OverlayFS and reboot again. There might be a way around this, but that’s for you to figure out.
A similar option is also available with sdtool, which is small piece of software you can run on your Pi that instead directs your MicroSD card to go into read-only mode – which all SD cards, big and small, are capable of. If you don’t run the latest Raspbian, or maybe you want to switch your card’s read-only status without reboot, this approach might could be basically made for you.
Something else you might want to try are eMMC chips. Designed to be suitable for an OS to run from, they also happen to be compatible with the SD card interface on the Raspberry Pi, and you’ll find some Pi-compatible ones for sale using your search engine of choice. Recently, someone who swore that they held one of these mythical Pi 4 Compute Modules (reportedly, for a few seconds) told me that they use onboard eMMC storage. Not that the Out Of Stock warnings make me feel hopeful I could ever really verify, but if that’s indeed the case, how bad could it be?
A Little Corruption Can’t Hurt
The amount of stories about Raspberry Pi card corruption is daunting, but it’s a drop in a bucket when you consider that forty million of them have been sold. This is the gist of what goes into a typical SD card corruption case. If you ever need to deal with pesky SD corruption problems, you now know what to look for, and likely learned some new variables you can tweak. Get a good card, a good power supply, and don’t let others’ negative experiences, real or rumored, get you down!
I think that PI just needs beefy tantalum capacitor which will only provide power for the SD card. So if you have unexpected power outage, the SD card will still have power for second or two after the CPU is shut down. Obviously you need at least schottky diode or something to prevent CPU sucking the power from the SD card cap right before it dies.
It would be nice if the boards have some build-in ups and auto shutdown when the power supply stops unexpected. That ups probably just a properly speced capacitor.
I’ve been meaning to look into “which of these pi UPS solutions are legit” for a while now and get one.
I really could probably just do an overlayFS though. Anyone know if it works over NFS?
I’m currently using the juice4halt, UPS with supercapacitors. So far it has worked very nicely. It does cost about the same as the Pi itself however.
Absolutely. It’s not as if we are still in the days of flooded lead acid batteries.
It should be a standard feature. A LIPO through battery operation and a power down signal.
It seems a good idea to use a Supercapacitor + UPS circuit.
Tantalum cap’s have their own reliability issues.
For one, they don’t ‘like’ surges, and can be damaged by them. SMD Tants especially need ‘annealing’ after the soldering process, to relieve internal physical stresses that can (and do!) Cause failures later. Especially on parts used to decouple power rails. (I have seen too many of those failures in my work life.)
Wet electrolytics are more reliable in that respect, but of course they have their own issues over time.
Best of all, use a good quality power source, that is quiet, and well regulated. Then it is only transient decoupling that is needed, and that can be done with non-polarised solid dielectric parts.
Take care.
But you still need SD card to loose power later than CPU so it has time to finish its wear leveling magic after CPU has written something to it. That cannot be guaranteed when they both use the same power rail.
SD cards take upwards of 50mA during write. Using just a capacitor, you would need 50mF to keep it supplied for 1 second with 1 volt drop. Using a buck regulator would improve efficiency, but it is still firmly in the supercap territory.
>ctrl+f log2
>None
https://github.com/azlux/log2ram
More than just a bandaid for your SD!
Should be built in
Never understood why a Kernel Ring Buffer could not be used to achieve a similar result. Not everybody wants to keep all the logs if the buffer is full.
i’m not sure this particular log2ram tool is that great, but i’m surprised the general approach isn’t more popular on pi. especially since there are pi-specific distributions designed for end users, i am surprised they don’t do something like this by default.
i have /var/log /var/tmp /tmp and even a few transient parts of my home directory hosted in tmpfs (or symlinked to tmpfs). and it’s enough that i mount root ro by default, and i only explicitly switch it to rw for a few minutes at a time.
after reading this article, i’m reminded that this is a happy-go-lucky naive confidence on my part, but i still do believe that simply not writing to the SD card very often will dramatically improve your experience with it. using a 2GB card that came free with some device a decade ago. no problems, though it’s only been a year. the other secret is backups (and NFS), of course.
the flip side of all this paranoia about wearing out flash is that for about a decade i’ve been using laptops with MMC for a decade and simply using rw ext4 on them, writing log and tmp to flash and all, as if they were regular spinning disks. when i started doing that, i was sure it would bite me, but it hasn’t. so i understand why people who have come to take that sort of performance for granted are probably pretty upset when they switch to SD on pi
Speaking of alternative distros for the Odroid SBC, there is armbian mounting /var/log exclusively to ZRAM devices. But I didn’t deep dive into more distros yet.
^This. After working to minimize writes from all sources on the various varieties of Pi in my house, I’ve had no further problems with SD failures. All solid for several years and counting.
Yeah, that is a key. My Pi’s mSD’s would last a couple months after constant use, but turning off/redirecting as many writes as possible really helps.
I have one that is going on 3 years now without issue.
Yes, this! I included this in my basic “new raspberry pi cheatsheet”: http://iivq.net/making-a-nas-out-of-my-raspberry-pi-4/
You can set Storage=volatile in /etc/systemd/journald.conf
And you can mount tmpfs (RAMdisk) to /var/log using /etc/fstab
If you need some files to be pre-created on tmpfs, you can configure that /etc/tmpfiles.d/
So you don’t need to install any special software to achive just that.
That defeats the purpose of having a log at all, when you can simply reduce the total amount of writes, as the log is dumped 1x day.
Thank you Frankel. Much needed and much appreciated tip.
Frankel offers the best advice on this thread.
Love the artwork
Try running something on the Pi that has a database with many write operations on it and you will get bitten sooner or later.
In my case it was Domoticz home automation. It would chew through SD-cards (even reputable brands and on an official Raspberry Pi PSU) in a matter of months. Changed to boot and run from USB stick and it ran for years without issue.
I have an SSD on my Rpi3 running Domoticz since a couple of years. And my Rpi3 power supply is backed up with an UPS. Before that, I had sd card corruption issues. Sometimes it was quite subtle: the pi booted but some commands failed. I got worse until I reflashed the sd card. I had only one very brutal crash due to sd card dying and the sd card never worked again. I had also flash corruption on a Beagle Bone Black running Debian on the emmc. If somebody could explain what the culprit was (I suspect too many write cycles despite log2ram and some actions to prevent unnecessary writes), I would be very grateful.
Ran into SD card issues with Home Assistant. Basically had a faulty USB cable (took me a while to pinpoint) which caused random restarts of Pi 4. And it killed one SD card every time. I mean write lock protection killed. Switched to an old hdd thru usb adapter and never had a problem since.
Also good to use DD to create images instead of using the unnameable ubiquitous woke bloatware pointed to in every howto. That corrupted more than one card for me before I returned to DD. It is sort of pretty though.
dd? Use cat or cp.
`sudo cp img.iso /dev/sdX` No strange syntax, no messing around with block sizes.
(Or `cat img.iso > /dev/sdX` if you’re root.)
dd is good for doing file start/end manipulation and offsets and such, but if you just want to burn a thumbdrive, you already know how `cp` works, right?
cat file.raw | sudo tee /dev/sdXY > /dev/null
I don’t know of any “woke” software. Do you mean that win32diskimager?
pretty sure he’s referring to Balena Etcher or Raspberry Pi Imager. Both of which I believe use the Electron HTML5 runtime and weigh over a hundred megabytes of node.js insanity. All to show you an ad for Balena Etcher Pro!
Sure it might feel overkill, but I know I’m not going to accidentally overwrite the wrong partition when using it. Make a command line tool that can say the same and is easy to install and I’ll happily consider it. (And I even know some lesser-used arguments to dd)
>> “neither will all the SD cards in our drawers”
I can’t speak for anyone else, but I’m constantly picking those things out of the laundry…
I’m still using DoD 5220.22-M
Your method may be more thorough.
I’m absolutely convinced in my own mind that there were fundamental issues with SDs on early raspberry pi’s, it was 50:50 if they were powered off without a proper shutdown, they wouldn’t come up again. But I don’t think I’ve had a corrupt SD card in the last 5 years though – even if I am brutal with them (I had thirteen power outages in the space of an hour in a recent storm, for example). I settle on 32GB sandisk cards sourced from Amazon these days, fwiw.
I share your views, my raspi sort of browns out even during normal reboots. Which I notice in BME280 sensor glitches, powered by the 3.3V bus. It sort of creates massive spikes in the data for barometric pressure. Don’t know how the BOSCH internally measures it (capacitive?) but it absolutely dislikes minimal fluctuations in power. Swapping the PSUs multiple times led me to believe it is the raspi itself glitching my sensor. Never happens during normal operation.
Gauge of USB cables are also a source of problems I was told.
I had the same problem with a bmp085 .
Are you using an original raspi psu?
Use c instead of python to get the sensor readings.
Yeah its on python3 smbus and original PSU and some with more amps for testing.
Good tip to use C, love python but it can be flaky.
SD cards still are not a good choice really, but I agree I’ve not had any trouble with them for ages on a Pi as they really have worked wonders on making them pretty reliable.
But a USB 2 spinning rust disk is often still faster in use, way cheaper for capacity etc, and the Pi 4 with USB 3 better still, or the CM4 with direct PCIe SDD oh boy so nice to use.
I’ve only had 2 SD cards that actually failed since the first RPIs came out. For me the corrupting/dying has been a non-issue. SD cards are cheap anyway. On most of my PI4s, I’ve went to just using USB 3.0 external SSD drives (Samsung T5s or T7s currently) or using USB 3.0 to SATA interface for using my old smaller capacity SATA SSD drives that were just in storage. Good use for them. One of those PI-4 systems on a T5 (running PI OS 32bit) has been running 24×7 for quite some time now. That system runs general services (Pi-Hole, NTP, redis, etc.) for my internal network. Just recently I added another 24×7 system running PI OS 64bit to my network for testing applications on that platform.
Getting authentic and bigger SDcards I think helps. As the SDcard does it’s wear leveling and ages, it’s likely to still function but with a shrinking overall capacity (once it runs out of the any extra it has).
A 32Gb card will not hit each bit nearly as frequently as a small 4Gb.
My pi B still gets corrupted after one bad shut down running pihole.
A few years ago I set up Pi3s on a couple TVs running Kodi so my parents could have a convenient way to stream TV shows off my NAS, cast YouTube from their phones, etc. For the first few months I found myself reflashing an SD card at least every other week as the systems would get unstable, I’d reboot, and then they’d fail to boot. I suspected SD card corruption was the issue, so I picked up some small SD cards and a couple USB sticks and set all the Pis to boot off USB. Not a single problem since, though if I need to set one up again OverlayFS sounds like a perfect solution, or I might try network booting.
As for power supply, I don’t know what these things want from me. I have tried everything from 4A tablet USB chargers to directly connecting a laboratory benchtop PSU to to the 40-pin header. No matter what the little lightning bolt icon is always there, telling me the power supply is insufficient. I can supply 5v at 10A on my benchtop and it isn’t drawing anywhere near that. What exactly does a Pi require for power, or how can I disable the lightning icon?
I have noticed that they complain when feed 5.0 volts.
Likely due to some minor voltage drop in the cables or something, but at 5.2 volts it is happy.
From memory that icon appears when the Pi internally sees the input as 4.8v – so presumably there is either a big resistive loss in your cable/connection or your bench supply needs recalibrating – for what its worth I’ve never seen that icon on anything but the crappy end of phone chargers or when running far to many pi’s at once off the same 5v rail (the PSU can handle the load but if you boot/stress a large chuck of them at once it lags enough for the running Pi’s to notice the voltage dip)…
It shows the icon when the sense voltage is below 4.65V. There’s a chance that one of the fuses might be out of spec. The official 4 supply is 5.1V and some aftermarket supplies were 5.2V
I once had a problem with a DMM, turned out to be a bad fuse. It didn’t open up, which would have been obvious, it just had high resistance, but not infinite.
The problem mainly exists in /etc/fstab having a default commit time of 10 seconds. By using the mount option commit=30, you reduce the writes to the card significantly. Even more if you move /tmp to RAM and use zram.
You’ll see this when you have a significant number of updates to perform via apt and try to do them all at once.
I ran into this with Octoprint and the change fixed everything.
Using zram for swap eliminated my mystery problems, but I still backup the SD card to an NFS mounted spinning drive on another machine to insure I have images of the machine state that I can re-flash
There is enough resistance in the power supply cable that when the Pi starts pulling high currents you get a voltage drop even if the supply is a rock solid 5v. Increasing the current rating of the PSU doesn’t make any difference in this case, you either need to provide a shorter/lower resistance power cable, *or* you need to supply more than 5v to compensate for the drop. That’s why the official PSU’s are 5.1v.
Very likely it’s the USB cable(s), few are actually built to spec and for really good power delivery they often need to be over-spec.
I have an external CD/DVD burner for my toughbook that will pretty much only work with its original short USB cable, anything else it just refuses even though it’s a standard A to Mini-B cable.
Unfortunately, much like SD cards, 99% of the stuff out there for sale these days is junk, so you’d have to buy from a known supplier (eg Amazon direct, not marketplace, or the likes of RS/Farnell) for a genuine USB-compliant cable made by adults who are paid-up members of the USB club.
There was a google Chromebook engineer a while back buying every USB cable he could find and testing it, putting the results online, and most of them were pretty bad – a few were dangerosly so – might be worth seeing if he’s got any recommendations:
https://www.theverge.com/2015/11/5/9674462/usb-type-c-google-engineer-third-party-cables
Samsung seem to be working with a different SD spec to everyone else, their devices kill or refuse to work with other SD cards, and their SD cards die real easy in other devices.
Strange, I’ve found Sandisk uSD cards to be consistently unreliable in Raspberry Pi and Samsung cards to be stable over years of use.
RW ver 0.0.3 is talking about Samsung devices corrupting non-Samsung SD cards, not unreliable Samsung SD-Cards.
Out of a sample of 1, I had an S5 do something odd to a branded (not Samsung, not Sandisk, begins with I I think, but not sure…). I noticed that files written to the card showed OK but if you tried to read them back there would be some error. Took me a while to realise the card was effectively permanently read-only, although it would happily allow you to write to it, nothing ever changed. Everything that was already on the card could be read back perfectly, just nothing written to it stuck.
Well yes there are multiple specifications of “SD card” interface too. Been there, done that.
Plain old SD single wire. MMC. SD 4-wire. It goes on….
A lot of the specs are proprietary and you have to pay to join the club (or find a knockoff copy of the specs.)
If you want max speed, you need the proprietary bits.
IIt’s a bit of a mess, really.
That’s why I have always preferred USB FLASH sticks over SD FLASH.
But then some USB FLASH providers straight out lie. Try a benchmarking test.
Yep, having an S6 Edge simply refuse to work with SD cards really made me sour about the SD standard for many years.
Then as I got more into electronics I found out that it was Samsung that had been at fault, because for everyone else original SD cards worked just fine.
I’ve had basically all my genuine Samsung SD cards spontaneously die, so I’m refusing to get any more. Sandisk hasn’t failed me yet, but I haven’t had long enough since the switch to know if it will stay that way.
I’ve never had a Pi corrupt any of the cards I’ve used, they’ve all worked perfectly well. My issue is rather with the (pre-RPi4) Pis having such excruciatingly slow SD-controllers. Even when overclocked to 100MHz, the controller just can’t do much. What’s worse is that the controller doesn’t support UHS-standards, so it creates interesting situations like e.g. the A2-classed card, which should be much faster, actually ends up being slower than an A1-classed card because of the controller being dumb and useless.
I don’t have an RPi4 or Zero W 2, so I have no idea, if they’ve got any better controllers, but the slowness is kind of annoying on the earlier ones I do have.
Like you I’ve never experienced an SD card failure, and I’d consider myself a fairly regular user since the very first Pi came out and I’ve had servers using them continuously for long periods at a time. Now for speed I have switched to either USB sticks for lesser needs and SSDs for more serious projects.
I am sympathetic to those who have corruption happen and clearly it is “a thing” but I do get the impression that there are plenty of people who use this as a catch all description for when something unexpected has happened, is misconfigured or they’ve used poor quality equipment.
I think its also a little bit of inertia as the early days of the Pi did have a big tendency to corrupt SD cards at even slight provocation, which is largely a fixed problem now, but it was true so you expect it to be still.
Now its just that SD cards really are not suited to running a computer, which even with the right configuration to minimize the problem is never going away entirely – and the defaults are to still log everything (for good reasons with all the newbies needing help), so many more writes.
Reminds me of the Chumby which has had lots of troubles with uSD cards too, and that lead to an investigation of fake cards with faulty controllers. Chumby was from 2006, quite a few years before the raspi.
https://en.wikipedia.org/wiki/Chumby
I never liked the idea of using a uSD for the OS much.
It always felt as a 2nd or 3rd rate solution.
I really do like the way that Hardkernel uses eMMC modules and made them swappable by adding a connector.
While modern Pi hardware is less likely to create bad areas of flash, they also are harder to overclock the i/o speed. And no, the reliability issue was never really solved by the foundation, and the community had to burn a lot of cards to work around the problems.
All Flash memory is not created equal, and this extends well beyond brand specific quality.
SLC lasts for >100k cell re-writes (fastest)
MLC lasts for <30k cell re-writes
pseudo-SLC on MLC / eMMC lasts for <20k cell re-writes
TLC / 3D-cells lasts for <5k cell re-writes (can be as bad as <300 on some brands)
Any modern sdcard or micro-sdcard is almost certainly an MLC based flash if over 32GB, and all are affected by excessive temperatures.
What this also means is file-systems that do not wear-level the storage can fail far more quickly (FAT dir or ext4 log area). Most modern SSD use sector sparing, transparent wear leveling (bigger empty drives last longer), ram caching, and mix technologies in hot-write regions of the disk (assume NTFS). Only some sdcard models will utilize a few of these technologies, and brands like Sandisk/Samsung often label such cards as “high-endurance” or “Extreme Pro” versions.
FYI, testing dozens of brands of SSD has also revealed lot specific performance degradation for the same model numbers. i.e. after all the reviews are out on the web, the SSD start to get worse 6 months later with cheaper flash dominating the designs.
A Ramdrive OverlayFS with a Ext4 backing partition is highly recommended for root. For /home a logging file-system like F2FS can often increase flash life by 70% (all variables held equal) or more.
If you think this is a myth, than it sounds like a flippant troll… ;-)
Finally, someone mentions F2FS. I really wish that this would be the default filesystem of the Raspberry Pi OS.
I used it for some time, don’t remember if I’m still using it. I do remember it caused trouble when I tried to use Docker which was subtle and annoying. I do wonder why it’s not more widely used though.
F2FS is a file-type aware filesystem, and Docker uses several overlay technologies for the instance disk images.
Docker and Kubernetes can add a lot of overhead to systems, and are generally an indicator of undesirable polyglot stacks. One essentially tosses out the linux shared library object paradigm, and adds a slew of other complex-load failure modes.
I am not saying Docker is a fault, but rather people use it in ridiculous ways.
;-)
If you want to build device to work for some time and not just tinker around its worth to manage using buildroot or yocto. Read only image means low chances of corrupt card and 2s boot time is bonus
^This is how I have deployed 30 or so RPi’s and they run for years without a problem. Some have been up for 9 years serving up a firewalled VPN and remote control.
Turning off logging and selecting a non-journaled file system solved it for me. That Pi has now been up for getting on for 10 years with the same SD after the first one died within months.
I was developing a commercial product with a Pi in as a router and monitor. As it was specced for extended temperatures I used an industrial spec SD card, from Farnell I think. It cost about 10x what a similar standard spec SD card would be.
However these cards seemed ultra reliable and I don’t think we had one go wrong, which is quite important when you ship something out that goes up a pole.
P.S. Yes I know the Pi isn’t officially temperature rated, but when I was someone running one while dipped in liquid nitrogen, I had some confidence, and temperature testing in the environmental chamber showed no problems at all.
Just out of curiosity: why did you choose pi for this project?
I have one camera (Canon EOS 750D, marketed as Rebel T6i in the Americas or as the Kiss X8i in Asia) which chews trough SD cards. I have tried updating firmware, never filling the card more than halfway and all brands and types of card, but roughly once every 6 months it mauls an SD card such that I can’t save pictures to it anymore. All but one times I could still read pictures off of it in the pc, so that was ok at least.
1. Canon EOS tend to overheat (ages flash faster)
2, buy your cards from a local retailer like Best-Buy etc.
3. get cheap 16GB sandisk cards, and never delete your photos to reuse the card
This means your camera will work… rather than gamble on it glitching up.
I’ve not noticed any overheating on my two EOS or any trouble on the sd/cf card that straddle IIVQ’s in age and quality – older ‘cheap’ one and slightly newer but still half frame more professional one, but then if you use them for stills you probably won’t put any real heat into them anyway…
And most of the ones that do movie recording seem to be ok at staying sufficiently cool, its just that newish monster that does 8K video that really gets rather toasty, and only while doing 8k video from what I’ve been reading – do please point out any info on ones I’ve missed though – been looking at perhaps getting a more recent DSLR or mirrorless – from canon as those are the lens I already have, and I’ve had no trouble with my very cheap old second hand ones, not sure I can find the budget, but it would be nice, mostly to have one with the flexible screen mount so those awkward positions you can still get a good live view (though I’ve generally preferred looking through the viewfinder for stills)…
My 650D managed to make a really expensive fast card slow…
This kind of explains why my Cheap Android Phone died ….
– either it had to be the problem with the PSU or thin wire runs, or I got one of those Ghost run Sim Cards. IT pays to read up one other CPUs problems to give you insight to problems you might be having.
Doesn’t the need to erase an entire block before writing to it cause some of the corruption issues? Regardless, I too had terrible problems with SDcard corruption in the early days — lost a customer because of it, even. There’s a reason I rejoiced when USB boot and PXE boot became viable options.
While I’m using the oficial power DC, 0 corrupted!
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.
I had an SD card die suddenly in a pi 3b.
I dropped the cased pi onto the floor, about a 2 metre fall, and it landed on the edge of the case where the SD card sticks out a tiny bit to be removable.
I wonder how many Pi problems are brought on by people using some of the thousands of cheap knock-off bits or kits sold all over ebay, amazon, etc. with cheap power supplies, cables, off-brand or fake SD cards, etc.
Given that thousands of these are bought for children by parents who may not be tech-savvy and likely on a budget, at the behest of schools, I can see a lot of opportunity for this sort of thing in the wild.
After all, to most people, a USB phone charger is a USB phone charger.
Do “high endurance” cards provide any reliability advantages in a Pi?
A good point. I switched to such a card. Its slower but since two years no problems. But maybe with a normal card i could also had no problems? How knows?
They do appear to have benefits. I’m pretty sure “Explaining Computers” on YouTube (a great source of sbc info) verified this.
For those curious, I have been running unbound and pihole together. My SD card finally failed after about three and a half years. I have the image backed up so I just grabbed a new one and popped it in. No idea if booting from USB is a thing yet, but it should be.
It is a ‘thing’ … at least on my RPI 4s and 400s. I don’t use SD cards with these boards. Just load PI OS on external USB 3.0 SSD drive and go.
It is on Pi3 also. Basically a small SD card with a static bootloader image that boots off USB.
I have an older RPI. Each loss of power rendered it unable to boot, reinstalling on the SD card restored function till the next unexpected shutdown.i replaced the SD card with a name brand, yet the same issue persisted.
I then changed the power supply to a name brand 3A charger, well above specified requirements.
I have not had an issue since. A dozen power cuts. I am so cocky now, if I need to move it I just pull the plug.
I had read before than the required power supply is under specified. An RPI will run but is not robust to variations during runtime without a beefy power supply.
Nice article, speaking of the UPS issue, I recently saw ExplainingComputers Video on the Raspberry Pi Waveshare UPS HAT that has a Version Powering the Pi from the bottom (so less HAT and more HAB) with Pogo Pins.
I wonder if the contact area is big enough to power the Pi even during high current events without issue
Two things that really annoy me about the raspberry pi – no option for a power button, and power supply issues. I have several good quality power supplies that can supply a stable 5v3a, and the pi still complains about them
I got around the no power button by buying a few cords with a switch or push button built in-line.
So, not good quality power supplies then….I suspect the cables are crap.
Use industrial Grade SDCards with built in power fail protection: https://www.swissbit.com/en/products/nand-flash-products/sd-memory-cards/
I have only bought RPIs (v3 and v4) from official UK distributors accompanied with the brand labelled recommended power supply – 5 so far.
With no peripherals other than keyboard and mouse attached I always see the ‘lightning bolt’ alarm – so if the recommended supplied power supply is inadequate – then you will see more problems – as I have.
I find that almost incredulous, as the official Pi chargers of the same era as the Pi 3 and 4 have more than enough grunt and supply the high end of USB spec voltage too…
Your keyboard or mouse would have to be stupendously power hogging, or perhaps just somewhat greedy if you have set a really impressive top end overclock for that to be remotely true – either you got sold a knock off, or a dud on the powersuppy – its got to happen sometimes. Or I suppose you could be lying…
I’ve been able to run NVME USB3 SSD (which are pretty damn power hogging), and a pretty power hogging Keyboard (an old PS2 mechanical keyboard with scancode to usb converter) and mouse with significant overclock (but not the max the siicon can take – not enough cooling at that time) off the official one on a Pi 4 and not had issues… Still the go to high power 5V supply I grab even now the most used Pi’s have neater solutions for their locations…
Oh after writing this I realized you might also have in error purchased the lower spec but still official power supply from the earlier less power hungry model, in which case hitting problems would be expected, to start with I thought you bought a BUNDLED set (which would presumably have the correct PSU for the Pi model or better), then realised you might not mean that…
Hiya – I bought the Pi’s and power supply as separate items from the same supplier – the power supply offered was described as being official and adequate – it was the only one advertised on the site so I was unaware that there were lower specs available and these may have been such. The wired keyboard/mouse were just generic units with the smaller keyboard from the same site. I didn’t buy the bundles offered as I preferred an aluminium case with a fan.
Those PS cannot be official, you would need all sorts of extra stuff plugged in to be seeing the power alarm when using the official supply.
My pi 3 does appear to have worn out its current card, or at least I think so: when trying to do stuff on it, it will freeze up for quite some time before continuing. I’m guessing it’s the InfluxDB role it used to play.
Now that I’ve upgraded most services to a different machine as server (an old thin client) things are much smoother but the pi still freezes, so I think I need a new card. Even though the new server now has a Samsung 860evo SSD in it, the regular approx 1/second flicker of the disk light makes me anxious I’m gonna burn it out too…
Please, please use a power supply that is made to supply a Pi. 90% of these issues come from people using Won Hung Lo wall-warts that have a 4.8-4.9V output. A Pi works best when the supply is OVER 5V. 5.1V is good, 5.2V is better. Pi Foundation PSUs do it by default, and if I have to use an offbrand power pack, I modify the feedback voltage divider to increase the voltage. It fixes the random SSH dropouts, failed SD writes, dropped WLAN connections, cluelessly exiting SCREEN sessions…
I wrote a small script to help me identify SD cards on my Raspberry PI’s.
It’s surprising where they come from and appears they are not always as branded.
https://github.com/OneOfTheInfiniteMonkeys/sdinfo
Since the very early days of an unbranded SD cards and a crashes that seemed ‘odd’ on the venerable Model B. I moved to 5.1 Volt power supplies and Samsung Evo Plus 32 GB or Sandisk Micro SD Cards. More recently moving to Sandisk High Endurance. To date with 6 Raspberry Pi models running 24 / 7 for a number of years, I have experienced zero Micro SD card issues. I still take full .img disk image backups of the cards before significant changes. Though mainly to save the pain of re-creating an installation from my lengthy set up notes.
With working pattern changes, I can’t imagine Pi-Hole (sponsored) being down and am planning a full off line standby.
We’ve been using Pi 2s here now for more than 5 years plugged into TV screens and using the power from the TV’s USB ports. Every work day they get booted when the TV is turned on and then at the end of each work day they get turned off when the power switch on the TV gets pressed. Most of the 8gb SD cards have been incredibly reliable and luckily beacuse they’re older Pis they can run off the relatively low current the TV’s USB port supplies without issue. They run a published Google slide show via Midori in kiosk mode to provide information to students. Maybe I’ve been lucky!
A high quality uSD card can help a lot. Swissbit makes some. They are a good bit more expensive but worth it.
I’m currently booting and running a headless raspberry pi 4 off a low voltage WD 2TB SSD USB 3.0. Runs a complete LAMP STACK and hosts a WordPress site with really no issues.
It boggles my mind that rPi doesn’t use a read-only initramfs to boot like most other SBC systems do. The initrd image file is kept on the FAT boot partition and contains storage recovery tools, so that before continuing to boot to the root filesystem on the ext4 partition it can do recovery and at least report a problem, or restore a backup over WiFi.
But for some unknown reason to me, rPi steers vastrly clear of this industry-accepted approach.
I have yet to find even a straight forward document by rPi that describes how to use an initramfs. It would be make the Raspberry Pi Imager much more attractive.
I got the Raspberry Pi 4 B. I used numerous class 10 SanDisk MicroSD cards and they all ended up in the rubbish bin, all new. Totally corrupted, not even the PC accepted any of them anymore. I changed the boot order to USB-MSD and the problem disappeared, I use only USB flash memory drives. The SanDisk MicroSD cards were all Made In? CHINA, you guessed it. Hahahahahahahaha.
Hello.
I regularly have that corruption problem with my Raspberry Pi 3B, which has its partition table corrupted, maybe once a week.
But I studied my case (is it the same as yours? I don’t know), and I made some observations which lead me to ask the following question: are we really sure that this is a hardware problem with the SD card, and not a software problem?
My observations are the followings:
1) After corruption, I can mount the SD card to another Linux system, check it using “fdisk -l”, and I can see that some partitions in the logical chain (I use MBR partitioning with logical partitions) have simply vanished.
2) If I dig across the whole disk using “dd” and “hexdump”, and look at the MBR contents (I created a bash script for that), I can see that the logical extension sector for that partition has simply be reset to zero.
3) The corruption concerns always the very same sector. Which, in my case, is NOT the first sector of the SD card volume.
4) Even after corruption, I can mount the SD card to another Linux system, use “fdisk”, and recreate the vanished partitions with the same values they had before (I previously saved these values using “fdisk -l > somefile.txt”). After that, if I put the SD card back on the Raspberry Pi and power it up, everything works perfectly. Nothing else seems to have been damaged.
Could a hardware problem always corrupt the very same sector with the very same contents, without causing any damage anywhere else?
And I even observed something even more interesting:
There doesn’t even need to be a power outage, and in fact not even a regular power off, to cause this partition corruption.
I have found that this can even happen while the system is running, possibly after a long time, without anything significant causing it. Still just using “fdisk -l” to check every now and then.
So I wrote the following PHP script:
—————————————–
#! /usr/bin/php
<?php
$fdisk_output = shell_exec('/usr/sbin/fdisk -l /dev/mmcblk0');
if (strpos($fdisk_output, 'mmcblk0p7')) { // Replace mmcblk0p7 by your partition name
echo "Everything is fine.\n";
exit();
}
echo "Some partitions vanished.\n";
$dump = shell_exec('/usr/sbin/fdisk -l /dev/mmcblk0');
$msg = <<
—————————————–
(this implies having installed PHP and some email resources like “nullmailer” on your Raspberry Pi, of course)
And then I setup a cron task for running this every 15 minutes :
0,15,30,45 * * * * /mypath/myscript.php > /dev/null #Check partition corruption
This works perfectly.
Yesterday, for example, it started warning me by sending emails every 15 minutes beginning at 11h PM (23h), in the middle of no special time.
I fixed it immediately without even rebooting (this implies ignoring the “fdisk” warnings about the fact that the disk has mounted partitions).
I suggest anybody having SD cards corruptions to try the same thing.
I suspected something like that. I experienced several times errors when using the CLI. The symptoms were files that couldn’t be read and commands not found (in the usr/bin or /usr*local/bin/area especially). Difficult for me to try as I moved from sd card to ssd on my home Rpi, but definitively save it in my script collection.