News for hackers. Stuff that matters.
Re:Raspberry Pi microSD card performance comparison by monocasa on Friday April 06, 2018 @08:23PM (#16778659)
At least for me, the failure mode in most cases had the card simply erroring out on accesses (even writes!) to particular sectors. Other sectors would allow to write, so it wasn't that the card had run out of sectors with write lifetimes. When you're not given anything to work with, even corrupted data, extra ECC isn't going to do you any good. My conjecture (with no data) is that the card's FTL was itself corrupted.

EDIT: and in no cases I saw did the cards I was testing give me truly 'corrupt' data. Just either error codes, or stale data, or occasionally data from another sector entirely. They've got metric shittonnes of ECC internally (to make up for the crappy NANDs), and will do a better job than you can at detecting errors.

Re:Raspberry Pi microSD card performance comparison by zzzcpan on Friday April 06, 2018 @08:40PM (#16778736)
Right, so, if we use virtual blocks the size of the physical blocks and either parity block or one of the data blocks are destroyed it is still possible to get the data. And with writes if a write fails our layer can just try to write a bit farther and farther until it succeeds.
Re:Raspberry Pi microSD card performance comparison by monocasa on Friday April 06, 2018 @09:09PM (#16778846)
In general you don't have access to the physical block size. And it can change even within a given lot.
Re:Raspberry Pi microSD card performance comparison by zzzcpan on Friday April 06, 2018 @09:30PM (#16778921)
Exact block size is not necessary, big safe choice is fine too. But I suspect it's trivial to detect it with benchmarks, as writing even a byte over a block size would require overwriting two physical blocks instead of one, which is much slower.