MMC quirks relating to performance/lifetime.

[Andrei Warkentin]

On Mon, Feb 14, 2011 at 2:22 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>>
>> As I mentioned, I am checking with T right now on whether we can use
>> suggestion (1) or
>> suggestion (2) or if they need to be combined. The documentation we
>> got was open to interpretation and the patch created from that did
>> both.
>> You mentioned that writing in reverse is not a good idea. Could you
>> elaborate why? I would guess because you're always causing a write
>> into a different AU (on these Toshiba cards), causing extra GC on
>> every write?
>
> Probably both the reliable write and writing small blocks in reverse
> order will cause any card to do something that is different from
> what it does on normal 64kb (or larger) aligned accesses.
>
> There are multiple ways how this could be implemented:
>
> 1. Have one exception cache for all "special" blocks. This would normally
>   be for FAT32 subdirectory updates, which always write to the same
>   few blocks. This means you can do small writes efficiently anywhere
>   on the card, but only up to a (small) fixed number of block addresses.
>   If you overflow the table, the card still needs to go through an
>   extra PE for each new entry you write, in order to free up an entry.
>
> 2. Have a small number of AUs that can be in a special mode with efficient
>   small writes but inefficient large writes. This means that when you
>   alternate between small and large writes in the same AU, it has to go
>   through a PE on every switch. Similarly, if you do small writes to
>   more than the maximum number of AUs that can be held in this mode, you
>   get the same effect. This number can be as small as one, because that
>   is what FAT32 requires.
>
> In both cases, you don't actually have a solution for the problem, you just
> make it less likely for specific workloads.

Aha, ok. By the way, I did find out that either suggestion works. So
I'll pull out the reversing portion of the patch. No need to
overcomplicate :).