[Arm-dev] File system corruption

Gordan Bobic gordan at redsleeve.org
Thu Dec 13 22:48:47 UTC 2018

On Thu, Dec 13, 2018 at 7:59 PM Stephan GUILLOUX <stephan.guilloux at free.fr>

> On 13-Dec-18 18:16, Gordan Bobic wrote:
> > You are likely to find that stress testing will kill most SD cards
> > within a day or two. They simply aren't designed for small write
> > workload. They are designed for large streaming writes (and they are
> > fine for reads, obviously).
> >
> > "Endurance" models fare much better, but you will still kill then
> > quickly with continuous small random writes.
> Starting point was exactly this.
> We saw FS corruption very lately, with very strange effects (especially
> when you are used to only SATA drives).
> One of them can be depicted like a ReadOnly FS not so ReadOnly ... Once
> formatted, the SD was working fine for a while.
> So, trying to narrow that down, mixing 3B and 3B+, with many devices,
> many different HATS, many different stuff, it came to the stress test
> and mount/copy/umount/fsck scenario, but yes, it took quite some time :-)
> The stress test will help us to perform some kind of qualification, for
> any new SD...

I suggest you only batch test models, rather than testing each end every
card in that way. You might find that the stress test uses up most of their
useful life.
To put it into perspective, even some proper SSDs from reputable brands use
NAND made in a process so small that it's only good for 75 erase cycles
(e.g. 1TB Crucial BX100 SSDs). It's not necessarily a problem with good
flash management (I've had a pair in my main workstation for  3-4 years now
in 24/7 regular workstation use, and they are showing something like 2-3%
wear), but with the quality of flash management you can expect from a
controller small enough to fit into an SD card, that's going to cause
problems. Worst case scenario, you could be looking at 100x write
amplification to the underlying NAND.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20181213/4538999a/attachment-0001.html>

More information about the Arm-dev mailing list