Howard Chu (hyc@symas.com) on 9/9/08 wrote:
>
>Well, you're presuming that there are enough free blocks to
>just write to in the first place, before the background
>coalescer runs. And also you're presuming there's
>enough time for the background task to run to completion,
>before an actual user I/O request arrives. The only way to
>make sure these operations succeed is to use an additional
>buffer/cache.

No, there's a much easier way to do that: just don't expose
all of the flash as addressable - keeping a certain amount
for private use.

You want that anyway in any remapping scheme, even if
you don't have issues with bad areas that you need to map
out. Trying to do block mapping on a totally full device is
really really hard. There are lots of algorithms that work
well as long as the device isn't full, but that start to
thrash and flail uncontrollably when blocks are 99% full.

So look at that 80GB drive (caveat: I'm going to get one,
but I don't have one yet), and I will bet you that it's
something like 10 8GB chips (or 20 4GB ones - I don't know
what current flash chip capacities are and am too damn
lazy to even look it up) - and the chips themselves are
"power-of-two-gigabyte", but the final end result is the
disk "power-of-ten gigabyte".

Do the math. The difference between a "Gibibyte" and a
gigabyte is about 7%. The end result is that you actually
have 5+GB of free space at all time! And that is how
you do wear levelling and remapping and how you erase
blocks in advance.

So I would bet that of that hidden space, one part of it
is for "fragmentation" (ie because you have remapped parts
of an erase block), one part of it is for actually keeping
track of the remapping information itself, and one part
of it is "pre-erased blocks". And there's probably a few
"bad blocks" there too.

What the exact distribution of those things is, I have no
idea, and it is quite possible - even probable - that the
distribution isn't even fixed. The size of the remap area
and the number of erase blocks will fluctuate as the flash
controller does garbage collection and compaction.

So the actual RAM buffer on the card is purely to keep any
temporary working results - there's probably a fairly
shallow cache there (a couple of flash blocks worth of data)
but there's also all the working memory for the flash
controller itself (ie the more complex data structures to
actually keep track of all the remapping information). So
there's no need for a lot of data on that RAM thing,
the flash itself is fast enough for that. You'd mainly just
have metadata there and the few blocks of WB cache.

But I have no actual insider information. All of the above
is based on just "that's how I'd do it, knowing how flash
file systems work".

Linus