Re: [RFC] read-only filesystem support for NAND flash devices

["Russ Dill" <russ.dill@gmail.com>]

> > Not quite the case.  You need bad block skipping, yes.  But NAND can
> > get bit flips in good blocks still.  How do you deal with that?  You
> > can't leave the block in that state forever because it will continue
> > to get bit flips and then your data will be unusable.
> Yep, I know about the issue. The recommended way to go here AFAIK is to
> mark the block as bad and copy its contents to a free one.
> However, this will make mapping a lot more complicated so I'd like to go
> another way, i. e. erasing and rewriting this very block, and if it
> wears out, cache the data read from it and schedule moving the data
> forward within the partition in a background. Does that make sense?

Then you'll run out of blocks. There are two seperate issues with NAND:

1) Bad blocks, NAND chips are shipped with a certain number of bad
blocks, during the chips life time, some of the other blocks will go
bad.

2) Reading from a sector degrades the data, but just a little tiny
bit. After several thousand reads, you may get a bit flip in your data
(which can be corrected by ECC). At this point, you do not have a bad
block, you just need to rewrite the data. You can't rewrite it to the
current block, because then a power loss would mean disaster. Also,
you can't mark the currently block as bad, because if you did, you
would decrease the usable life of your system (tons of good blocks
marked as bad)

So really,  for issue 2, you need some sort of free block list, so you
can reuse them. Which also means, you can expect the order of the
blocks on your filesystem to start to look more and more random as
time goes on. In other words, you also need some algorithm to find
which block is where.

Free block list? Bad block list? Tracking of block numbers? Sounds
like a full on FTL to me.