On Mon, Feb 14, 2011 at 2:22 PM, Arnd Bergmann [off-list ref] wrote:

quoted

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 :).