Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Can SD cards detect data corruption? / Linux kernel bug with SD Card Reader
Simple question really but impossible to find a definitive no-bullshit answer even after half an hour of Googling and DuckDuckGoing! It seems like there's ever-more information, but of ever-worse quality 
To rephrase the question: When data corruption occurs on an SD card (for example, due to cosmic rays or a cell losing its charge), will this be detected by the controller (through the use of checksums, for example) and an I/O error reported (good), or will the card just silently return the corrupted data (catastrophic)?
(if relevant: It's a Samsung EVO Plus 512 GB card.)
Comments
SD Cards are pretty "stupid". Compared to an actual SSD drive, you have fairly simple electronics on the card. No over provisioning, wear levelling and no background checks. It is usually the file system, that checks for errors and will try repeated read or write attempts before throwing an error. As a consequence card access will slow down, or you will get occasional read/write errors - time to replace the card!
While your data will very likely not silently change, you might experience sudden data loss in the case of an unrecoverable error.
OK, that's why I'm asking -- so, I had originally formatted this SD card with ext4. However, ext4 does not do any kind of error checking for the actual data (only for metadata). So ext4 is clearly the wrong choice for SD cards then, and after some research, I've decided to go with f2fs, with checksumming for data explicitly enabled during formatting (
-O extra_attr,inode_checksum,sb_checksum).Thanks for the input!
Shouldn’t they have been called Insecure Digital all this time?
No idea, I have no experience with them, but after 8 years, I had to get a new computer, and I chose the cheapest laptop in the cheapest SALE thing I could get
it didn't have enough internal storage for all my projects etc., so I got a -- hopefully high-quality -- MicroSD card for it. Just transferring all 250 GB of "stuff" to it and giving it brief breaks in between so it doesn't overheat etc...
(all these precautions might seem overly paranoid to some, but the idea of ~ 2 trillion (2,000,000,000,000) little charge cells in a piece of silicon much smaller than my small fingernail getting flipped in a matter of an hour just seems a little wild to my science-minded brain so I'm not taking chances... is this strange?)
Well, first test isn't promising! Copied 250 GB, then verified. 249 out of 129590 files were actually corrupted!
Now is this the fault of the SD Card, SD Card Reader, were they read errors from the source drive, is it a filesystem bug (F2FS), ...? No idea! Reformatted with ext4 now and copying and verifying again.
Update: f3write/f3read also report corrupted blocks, so it's definitely either the SD Card or the Reader.
Update 2: Tested with an external SD Card Reader connected via USB. No corruption. So it's the internal reader. Not returning the laptop because of that!
So, not putting any blame on Samsung or indeed MicroSD cards for now...
I bet that current SD cars do error correction internally, the chance that a single storage cell fails in such large cards is just too high.
I’ve had the same issues with SD card readers over the years, just remember not to rely on the data written or read from that reader.
it could be that older or more economical SD card readers don’t properly know about SDHC, and if they do, don’t know about SDXC, although this doesn’t seem plausible to me as they all have the same connections (except UHS-II which has extra pins)
incidentally and irrelevantly, the SD logo is recycled from an existing but unused (because failed) technology by Toshiba called the Super Density Disc, which was a DVD competitor!
Yeah. However, this card or reader clearly don't or it doesn't work!
No, I mean, it's completely unusable at this error rate anyway (~ 10 corrupted bytes per GByte of data written). Still baffles me how this can happen silently without any errors anywhere.
Heh. Yeah I mean I had read about SD cards being far less reliable than "proper" USB or "internal" SSDs etc., but I didn't expect it to be THIS bad!
That's the opposite of my experience. I have more than 100 SD/SDHC/SDXC cards used for backups and in digital cameras and only two of them have failed, many years ago, one is a Nokia 8MB SD and another is a counterfeit chinese Sandisk 32MB MicroSD clone.
Out of >120 USB sticks, about 6 have failed with 2 of them showing a messed up file system with only a few files left readable, and 4 of them dead.
Some sticks get very hot when writing a lot of data on them, that looks like a good reason for possible failures.
I never had a single corruption with Samsung, Sandisk and Verbatim cards and USB sticks so these are my choice until that may change one day.
But again, wasn't your card reader faulty?
So, it's all quite a complicated story (like most stories in my life recently 😂 but I'll prevail...) -- it looks like a Linux kernel bug now.
I've somehow managed to log into the Windows 11 install that my laptop came with originally (after going through 30 absolutely ridiculous M$ hoops because I was suspicious etc.), and I did the same write/read stress tests there with the same card and the internal card reader, and: no corruption! 😯
So the bottom line is: Corruption only occurs with the exact combo: Internal reader & Linux.
I've search kernel bugs and there's a report that sounds very similar, by someone using the exact same internal card reader:
https://bugzilla.kernel.org/show_bug.cgi?id=204161
(scroll to the bottom)
Crazy stuff!
Another thing to consider is that journaling file systems cause significant more disk writes and
Interesting. I am using Linux for over 30 years now, and internal card readers often caused problems. It did not matter if it were PCMCIA (anyone remember these?), MemorySticks (another vintage storage medium), Compact Flash or SD card readers. The USB equivalents usually worked much better. Even my current, only 12 years old Dell Inspiron refuses to recognise some SD cards - specially when they are unformatted. I never had a problem with corrupted data though. It was more generic problems with internal card readers not working at all, or only when they felt up to it.
Oh yeah, I had used
-O ^has_journalor whatever it's called so that would've been fine.Yeah, I must admit this thoroughly shocked me and actually made me paranoid now even with USB and internal SSDs, or indeed, any storage medium.
I hadn't seen "random" data corruption since the late 90s!
I know because I've never seen a single corrupted file in the past 30 years, until this point! Makes you nervous.
If ithis kind of bug exists in 2024, then how safe is your data really?
I was actually researching if there is any filesystem that will automatically verify every file or block of data it has written, right after writing it (i.e. reading it back from the device and comparing to the memory buffer). MS-DOS had something like this (
VERIFY), but it looks like random data corruption when writing to media is so "outlandish" these days that modern filesystems don't even support this anymore...So what's everyone's verdict now? Is it a genuine kernel bug? (would be shocking)... is it in the
sdhci_pcimodule (which is used for my reader)? Is it somewhere else in the kernel? Is the reader actually defective but the bug only occurs on Linux because different timings etc.? Who knows!Anyway. Watch out for your data integrity, guys!
NB: What shocks me isn't so much the data corruption (a few sectors per GB written). What shocks me is that it goes completely undetected! No
dmesgerrors. Nocperrors. Nothing. The data is just bad! How can it be that not a single one of the half-dozen layers of software/firmware recognizes this with some form of checksum etc.?Or maybe the card is faulty and the written bits just flip around again randomly a few seconds after writing (so something like
VERIFYwouldn't be able to detect it), and it only occurs on Linux because it's more "aggressive" or has sub-optimal timings when writing etc...I mustard mit that I’ve never heard of routinely formatting an SD card in anything other than FAT, or for SDXC, exFAT (although I’m fairly sure I’ve tried it myself in the recent past on Linux with ext3 but not for long as I found it unsatisfactory for a reason I can’t remember)
I can’t remember what I was going to say next, so I’ll just leave this here:
PCMCIA = People Can’t Memorise Computer Industry Acronyms
BTW @SevenSystems, although this article is rather about SD cards than readers, I found it very useful:
https://hackaday.com/2022/03/09/raspberry-pi-and-the-story-of-sd-card-corruption/
Thanks! That article actually came up during my research and fix attempts, but I only glanced over it. I'll give it another good read.