Joern Engel (joern@logfs.org) on 1/6/09 wrote:
>
>In particular, could you explain what the "right technical
>solution" is without depending on "Most filesystems..." as
>a basis? Majority votes are rarely a good design choice. ;)

The only sane flash model is one where the hardware itself
does the block remapping.

And no, this is not about "most filesystems" or about any
majority voting. It's a simple technical fact.

The simple fact is that exposing the internal flash
model to any external software is simply insane. You'd
never suggest that software should know about the exact
details of RAM DIMM addressing, and know about open
pages and the size and organization of banks.

Anybody today realizes that that would be total insanity,
and that you have a DRAM controller that does all that
in hardware. Yes, it will have a software component to it
to set things up, but even that component is effectively
hidden and done automatically. Not even system software
really ever needs to know.

Yes, flash is a bit more complex. It's not just about
timing rules and dynamic decisions about which pages to
keep open - because of the wear issues, you actually have
to keep track of long-term decisions. But the issues are
really no different.

It's simply insane to expect filesystems to know or care
about the odd flash rules of some particular chip. Yes,
it can be done, and yes, it has been done, but it
makes it no less insane. You need to have a flash controller
there anyway to wiggle the pins at the right
timing, and the only technically sane model is that that
flash controller also adds enough indirection that the
result can be treated as a single linear block device.

End result: if you see a flash disk that doesn't already
do wear levelling, that doesn't already do block remapping,
and that doesn't already handle random writes well, just
walk away.

It's that simple: the people who are trying to sell you
that crap are technically incompetent. You shouldn't buy
it, because you know it's crap. It was acceptable a couple
of years ago, but hey, so was doing the MFM encoding in
software for disks. It's not acceptable any more.

A software stack that isn't connected to the manufacturer
of the flash (ie a "generic flash remapping layer" like the
Linux UBI layer) simply cannot ever do as good a job as
just doing the thing on the flash controller. The flash
controller can take advantage of the physical behavior of
the flash much better, and can generally be tuned to one
particular type.

Yes, we'll probably see flash translation layers remain in
some extreme embedded environments, but certainly not in
any sane situation. And quite frankly, I doubt the "extreme
embedded" case remains very long either - since you end
up basically needing it even for the cheapest possible SD
card, the economics of scale actually pretty much argue for
raw flash devices not being all that relevant for anything
but firmware that gets updated a couple of times a year
and doesn't even need any of the whole remapping crud.

Linus