All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vipin Malik <vipin.malik@daniel.com>
To: mtd <linux-mtd@lists.infradead.org>, jffs-dev <jffs-dev@axis.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Wear Leveling in JFFS2 NOT working!(?)
Date: Mon, 30 Apr 2001 17:26:00 -0500	[thread overview]
Message-ID: <3AEDE678.51C6F94E@daniel.com> (raw)

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

             reply	other threads:[~2001-04-30 22:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-30 22:26 Vipin Malik [this message]
2001-04-30 23:06 ` Wear Leveling in JFFS2 NOT working!(?) David Woodhouse
2001-05-01  1:24   ` Tim Riker
2001-05-01  7:21     ` David Woodhouse
2001-05-01  7:43       ` Tim Riker
2001-05-01 12:35         ` David Woodhouse
2001-05-01 11:55       ` Jim Gettys
2001-05-01 12:29         ` David Woodhouse
2001-05-03 15:27   ` Vipin Malik
2001-05-03 15:29     ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2001-05-03 15:51 Chris Read
2001-05-03 16:09 ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AEDE678.51C6F94E@daniel.com \
    --to=vipin.malik@daniel.com \
    --cc=dwmw2@infradead.org \
    --cc=jffs-dev@axis.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.