[PATCH]Add erase count tracking support in JFFS2

[zhao forrest]

>
>Nice explanation, thanks.  How are you going to deal with the race
>condition during block erase?  If the system fails during that time,
>the erase count is lost.
>
>Some options:
>o Pick the average of all existing erase counts.
>o Pick zero, if no block contains erase counts.  This is the average,
>   in a way.
>o Pick the average plus "a bit".  With this policy, the block won't be
>   erased for a while, so it can't continuously hit the same race.
>o Arrange erase blocks in pairs and store the erase count for the
>   block itself and its buddy.  The two buddies in a pair are
>   alternately erased, so we always have a backup of the current erase
>   count.

I choose the first option. Because after we implement the enhanced
wear-leveling algorithm based on erase count in the future, the average
of total erase count would make more sense.


> > diff -auNrp ./mtd/fs/jffs2/build.c ./mtd_new/fs/jffs2/build.c
> > --- ./mtd/fs/jffs2/build.c	2005-07-31 06:00:11.000000000 +0800
> > +++ ./mtd_new/fs/jffs2/build.c	2005-08-18 13:33:55.000000000 +0800
> > @@ -336,6 +336,10 @@ int jffs2_do_mount_fs(struct jffs2_sb_in
> >  		c->blocks[i].first_node = NULL;
> >  		c->blocks[i].last_node = NULL;
> >  		c->blocks[i].bad_count = 0;
> > +#ifdef CONFIG_JFFS2_FS_ERASE_COUNT_TRACKING
> > +		c->blocks[i].has_erase_count_node = 0;
> > +		c->blocks[i].erase_count = 0;
> > +#endif
>
>This is still unchanged. *grumble*
>

mmmh...Gleixner suggest I include all the patch code in #ifdef. Then
after a period of practical using, we'll remove all #ifdef if we
think the patch is good.
I have added additional comment for it in fs/Kconfig.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: erase_count_r3.patch
Type: application/octet-stream
Size: 19934 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050825/a21e0f74/attachment.obj