SD cards and DATA_STAT_AFTER_ERASE

[Arnd Bergmann]

On Thursday 14 April 2011, John Gilmore wrote:
> (Of course, when doing these writes, don't do one-block writes to the
> drive; accumulate a bunch of them into a single larger write.  If you
> know the erase block size, the code could seek to do writes of that
> size, aligned on that boundary - particularly after recovering from a
> series of blocks it doesn't need to write to.  But some cards may be
> able to erase several blocks simultaneously, and may thus prefer a
> write of N erase blocks.  Or cards may or may not care whether your
> writes are aligned (since they're remapping the blocks anyway through
> the flash translation layer), and may just prefer that you always
> write one or more erase-blocks' worth of data, no matter what the
> alignment.

Assuming that the card needs 4 MB aligned writes is a good approximation,
it is true for the vast majority of cards in production today, and I have
not seen any card report a different erasesize, even when it's clearly
something else. The only thing that generally matters for performance
is writing a multiple of 64KB as long as do do sequential accesses.

> Since reading flash is much faster than writing (and since one of the
> nasty aspects of flash is that writing block X can screw up the
> contents of block X-1 or X+1), would you consider reading back the
> entire drive after you're done, making sure the whole thing checksums
> properly?  (And also making sure that your checksum detects substitutions
> of entire all-1 blocks for entire all-0 blocks and vice verse!)

Doing a checksum sounds like a useful idea in any case. That will also
detect broken cards and those that have been modified to report a larger
size such as a 2 GB card claiming to be 8 GB.

	Arnd