Linus Torvalds (torvalds@linux-foundation.org) on 9/9/08 wrote:
---------------------------
>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.

Ah right. Absolutely right.

>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".

There are 20 4GB chips.

And yeah, just like the OCZ Core V2 128GB drive is now marketed as a 120GB drive.

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

Yes. Also there's apparently an ATA command you can issue to set the number of addressable sectors; you can decrease it if you want to reserve more space for remapping. (I dunno if you can increase it and steal back the reserved space. You probably wouldn't want to...)

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

The flash is only fast enough if everything else in the block management was done correctly; i.e., all incoming writes always mapped to sequential writes. It's obvious in the OCZ/Jmicron controller that this isn't the case.

>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".