Re: jffs2 flash life calculation

On Wed, 27 August 2003 11:41:20 +0100, David Woodhouse wrote:
> On Wed, 2003-08-27 at 11:22 +0100, David Woodhouse wrote:
> > If you have 12 blocks which are _half_ full because your usage pattern
> > tends to leave you with a mix of live and dead data, we have to
> > garbage-collect. If you have 6 blocks which are completely empty because
> > you don't have still-valid nodes interleaved between all the stuff you
> > deleted, that's ideal.
> 
> Note that our current garbage collection code is a little naïve and
> tends to cause the former... we should GC clean, long-lived data to a
> _separate_ block to which we're writing out new data. That way, we'll
> tend to get much better behaviour because the long-lived data will end
> up sitting in 100% clean blocks on the clean_list, while short-lived
> data are in mostly-dirty blocks which are quicker to GC.

We don't necessarily need two new blocks to write to.  Alternatively,
when starting a new block, we can force garbage collection and try to
fill this block completely with old, long-living data.  This will
gather all the old data from several erase blocks into one that can
remain static for some time.

This doesn't work perfectly if the machine isn't idle during this
forced garbage collection phase, but even then, we end up with a block
mostly filled with old data that needs garbage collection less
frequently than before.  And it is an odd machine where this doesn't
result in 100% old data once every couple of tries.

And of course, this should be done only once in a while, something
like the jiffies/100 trick.

Looking at the pros and cons, I guess the approach using two seperate
blocks for old and new data is always superior, as long as we have
enough space for it.

Jörn

-- 
The story so far:
In the beginning the Universe was created.  This has made a lot
of people very angry and been widely regarded as a bad move.
-- Douglas Adams?

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]