All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vipin Malik <vipin.malik@daniel.com>
To: Herman Oosthuysen <Herman@WirelessNetworksInc.com>
Cc: Cam Mayor <cmayor@iders.ca>,
	linux MTD mailing list <linux-mtd@lists.infradead.org>
Subject: Re: open question on flash speed/app blocking
Date: Wed, 16 Jan 2002 15:18:46 -0600	[thread overview]
Message-ID: <3C45EE36.4477E99A@daniel.com> (raw)
In-Reply-To: 000e01c19ec6$b2cd5980$0100007f@localdomain.wni.com.wirelessnetworksinc.com

http://www.embeddedlinuxworks.com/articles/jffs_guide.html

then

http://www.embeddedlinuxworks.com/articles/db_project.html

I've also done quite a bit of blocking time tests on JFFS2 (about 6-8 months
ago). See the (JFFS) list archives for details and graphs etc.

Vipin


Herman Oosthuysen wrote:

> Hmm, the problem is not writing to flash per se, but rather garbage
> collection, which requires the erase of dirty Flash sectors.  Erasing a
> sector on an Intel chip can take from a couple hundred milliseconds to about
> 15 seconds, depending on the age of the device - by the time a chip gets to
> 15 seconds, I usually toss them away.  Flash chips tend to get slower with
> age.  So, you have to repeat your tests a few hundred thousand times before
> you can draw any real conclusions.  This also means that the worst case
> performance will be about the same, irrespective of the file system used,
> since the hardware constraints will eventually dominate.
>
> If your system has to write to flash every few seconds, then consider using
> a file system that has a large write cache, to enable you to survive the
> periods when the system is busy erasing a sector.
> --
> Herman Oosthuysen
> Herman@WirelessNetworksInc.com
> Suite 300, #3016, 5th Ave NE,
> Calgary, Alberta, T2A 6K4, Canada
> Phone: (403) 569-5688, Fax: (403) 235-3965
> ----- Original Message -----
> From: Cam Mayor <cmayor@iders.ca>
> To: linux MTD mailing list <linux-mtd@lists.infradead.org>
> Sent: Tuesday, January 15, 2002 11:18 AM
> Subject: open question on flash speed/app blocking
>
> Hi all,
>
> We're making an app that periodically writes a persistance file to flash.  I
> haven't actually gotten a flash file system area working yet on my board, so
> i can't test this yet for speed.   I know that the results will vary with
> the
> hardware, the filesystem used, and a handful of other factors.  I'm assuming
> that a write to the flash will be blocking - that is, nothing else will be
> allowed to happen on the bus while that function is being performed.
>
> For a file the size of 32bytes, 1kByte, and 32kBtyes, what kind of blocking
> delay might one expect from linux writing to flash for each of those file
> sizes?  What would be an optimum flash filesystem to use for something like
> this?  (if there is one)
>
> cheers,
> cam
>
> ps. i'm using linux 2.4.6-rmk1-rayl1 and 2.4.16-rmk2.  I could use the
> latest
> kernel, too, i just haven't gotten around to it.  For development purposes,
> i'm using a cirrus CDB89712 development board, which has the cs89712
> processor and some Intel 28f320B3 flash on it.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2002-01-16 21:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-15 18:18 open question on flash speed/app blocking Cam Mayor
2002-01-16 19:47 ` Herman Oosthuysen
2002-01-16 21:18   ` Vipin Malik [this message]
     [not found] ` <000e01c19ec6$b2cd5980$0100007f@localdomain.wni.com.wireles snetworksinc.com>
2002-01-16 22:47   ` Mark Sienkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2002-01-15 18:44 Christopher Fowler

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=3C45EE36.4477E99A@daniel.com \
    --to=vipin.malik@daniel.com \
    --cc=Herman@WirelessNetworksInc.com \
    --cc=cmayor@iders.ca \
    --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.