Jffs2 and big file = very slow jffs2_garbage_collect_pass

Jörn Engel joern at logfs.org
Wed Jan 23 08:01:55 EST 2008


On Wed, 23 January 2008 12:57:09 +0100, Ricard Wanderlof wrote:
> 
> Perhaps it's possible to devise something that at least accomplishes part 
> of the goal. Such as when writing a new block, also write some statistical 
> information such as the number of read accesses since the previous write 
> (or power up), or the reason for writing (new data, gc because of 
> bitflips, ...) and a write counter. Something of that nature.

I'm still fairly unconvinced about the read accounting.  We could do
something purely stochastic like accounting _every_ read, but just with
a probability of, say, 1:100,000.  That would still, within statistical
jitter, behave the same for everyone.  But once we depend on the average
mount time of systems, I'm quite unhappy with the solution.

Also, logfs stores a very limited amount of data for each segment (read:
eraseblock).  Currently this is just the erase count, used for wear
leveling and the segment number.  The latter can be used to detect
blocks being moved around by "something", be it an image flasher,
bootloader, FTL or whatever.  There are still 16 bytes of padding in the
structure, so we could add an error counter without breaking the format.

> I'd be a bit wary of this with NAND chips some of which have a 100 000 
> maximum erase/write cycle specification, though. And I think that 
> especially when nearing the maximum value and going beyond it, that there 
> is some bit decay occurring over time and not just from reading.

It doesn't really matter whether the data degrades from a number of
reads or from time passing.  With a constantly high write rate, there is
less time for degradations then with a low write rate.

Problematic would be to have a high write rate for a while, then a very
low write rate that allows data to rot for a long time.  And also this
depends on your numbers being representative for every flash chip. ;)

Jörn

-- 
The only real mistake is the one from which we learn nothing.
-- John Powell



More information about the linux-mtd mailing list