Wear Leveling in JFFS2 NOT working!(?)

Vipin Malik vipin.malik at daniel.com
Mon Apr 30 18:26:00 EDT 2001


I setup a simple test to measure the wear leveling. During my power down
tests (which are at 10,090 cycles!) I print to the console which sector
is being erased.

Then using a simple program, I went through the console log and got the
following result: (Note! This data is only from 3615 of the total 10,090
pwr cycles).

Sector Address:0x780000 Number Of Erases:2050
Sector Address:0x640000 Number Of Erases:1573
Sector Address:0x600000 Number Of Erases:1503
Sector Address:0x5c0000 Number Of Erases:1406
Sector Address:0x580000 Number Of Erases:1297
Sector Address:0x500000 Number Of Erases:1045
Sector Address:0x4c0000 Number Of Erases:824
Sector Address:0x7c0000 Number Of Erases:2283
Sector Address:0x740000 Number Of Erases:1906
Sector Address:0x700000 Number Of Erases:1817
Sector Address:0x6c0000 Number Of Erases:1753
Sector Address:0x680000 Number Of Erases:1654
Sector Address:0x540000 Number Of Erases:1190
Sector Address:0x480000 Number Of Erases:514
Sector Address:0x440000 Number Of Erases:216
Sector Address:0x400000 Number Of Erases:60
Sector Address:0x3c0000 Number Of Erases:13
Sector Address:0x380000 Number Of Erases:1

Total Unique Sectors Found= 20, total sum of all erases=21105

Obviously, not all sectors are being "cycled" evenly. As a matter of
fact, none of the sectors below 0x380000 are being cycled at all.

I am using 4x wide 8bit memory for a total of 8MBytes (for a total of 32
sectors). 12 sectors haven't even been touched.

The fs is a "root" fs, with about 4-5Megs of the 8MB with static OS data
and the rest being used to write out 100 binary files (about 100-400KB
total).

Now, one thing that may be tripping up the wear leveling algorithm is
the fact that the system is being cycled every 2-3 minutes.


David? What does the algorithm to "pickup" a new "less cycled" sector
and give a over-used sector a rest depend on?

Thanks

Vipin






More information about the linux-mtd mailing list