Jffs2 and big file = very slow jffs2_garbage_collect_pass
Ricard Wanderlof
ricard.wanderlof at axis.com
Wed Jan 23 04:23:55 EST 2008
On Tue, 22 Jan 2008, Jörn Engel wrote:
> - Moderate: one block continuously spews -EUCLEAN, then becomes
> terminally bad.
> If those are just random bitflips, garbage collection will move the
> data sooner or later. Logfs does not force GC to happen soon when
> encountering -EUCLEAN, which it should. Are correctable errors an
> indication of block going bad in the near future? If yes, I should do
> something about it.
I would say that correctable errors occurring "soon" after writing are an
indication that the block is going bad. My experience has been that
extensive reading can cause bitflips (and it probably happens over time
too), but that for fresh blocks, billions of read operations need to be
done before a bit flips. For blocks that are nearing their best before
date, a couple of hundred thousand reads can cause a bit to flip. So if I
was implementing some sort of 'when is this block considered
bad'-algorithm, I'd try to keep tabs on how often the block has been
(read-) accessed in relation to when it was last writen. If this number is
"low", the block should be considered bad and not used again.
I'm also think that when (if) logfs decides a block is bad, it should mark
it bad using mtd->block_markbad(). That way, if the flash is rewritten by
something else than logfs (say during a firmware upgrade), bad blocks can
be handled in a consistent and startad way.
>The list probably goes on and on. And I am sure that I would miss at
>least half the interesting cases if I had to create it on my own. But
>if Matthieu or you or anyone else is willing to compose an extensive
>list of such failure cases, I will walk through it and try to handle
>them one by one.
We ran some tests here on a particular flash chip type to try and
determine at least some of the failure modes that are related to block
wear (due to write/erase) and bit decay (due to reading). The end result
was basically what I tried to describe above, but I can go into more
detail if you're interested.
/Ricard
More information about the linux-mtd
mailing list