public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Matthew Cole <mcole@ati.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Follow-up to wearing / caching question
Date: Mon, 7 Feb 2005 20:52:09 +0100	[thread overview]
Message-ID: <20050207195209.GC25504@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <54CC136E5398384485619BC34B3A0F0B055D0DB0@ma00exh02.atitech.com>

On Mon, 7 February 2005 13:51:22 -0500, Matthew Cole wrote:
> 
> The question posed by Martin Neilsen leads me to write in search of an
> answer that I've been pondering for a few days.  I've been tasked with
> approximating the lifespan of the flash (JFFS2) filesystem embedded in our
> products.  Is there a best method for calculating the space required for a
> fixed-size file over a given lifespan?  If we want our flash filesystem to
> be available for an approximate lifespan of 20 years, given the
> wear-leveling duty-cycle of JFFS2, and an average block endurance of 100k
> write/erase cycles, would I need 150% of the file's size? 200%? 1000%?  The
> worst-case answer should be acceptable, but obviously, the most-realistic
> case is what we're aiming for.  The actual read/write duty cycle of the
> application is quite variable, so that adds some complexity to the problem,
> but a good guess for now would be that it writes the entire file out to
> flash once a minute.  But as that is an independent variable, maybe someone
> could help me solve for that over a span of duty cycles?

Assuming non-compressable data and zero jffs2 overhead simplifies the
calculation.

In your scenario, you write the file every minute, over 20 years,
which is about 60x24x365x20 or 10M times.  You can only write any
individual address 100k times, so the flash would have to be 100x
bigger than your imaginary file.

Another way to look at it is an imaginary 1MiB flash.  You can write
it 100k times, for a total of 100GiB written to it.  With 600M seconds
in your expected 20 years, that gives you ~160 Bytes/s average write
speed.  Not very much.

Is that the calculation you were looking for?

Jörn

-- 
Homo Sapiens is a goal, not a description.
-- unknown

  reply	other threads:[~2005-02-07 19:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-07 18:51 Follow-up to wearing / caching question Matthew Cole
2005-02-07 19:52 ` Jörn Engel [this message]
2005-02-07 21:36   ` Martin Egholm Nielsen
2005-02-08 15:09     ` Jörn Engel
2005-02-08  0:22   ` Charles Manning
2005-02-08 13:23     ` Jörn Engel

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=20050207195209.GC25504@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mcole@ati.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox