public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vipin Malik <vipin@embeddedlinuxworks.com>
To: Bjorn Wesen <bjorn.wesen@axis.com>
Cc: jffs-dev@axis.com,MTD for Linux <linux-mtd@lists.infradead.org>
Subject: Re: On the "safe filesystem" and write() topic
Date: Sat, 07 Jul 2001 08:06:40 -0500	[thread overview]
Message-ID: <5.1.0.14.0.20010707075247.00a67798@mail.spewey.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0107071113490.18935-100000@godzilla.axis.se>

At 11:25 AM 7/7/2001 +0200, Bjorn Wesen wrote:

> > HeHe, well, maybe the fs can (will or may?) block, but in all realistic
> > situations it's unacceptable for a real world embedded app to block for
> > multiple seconds while the fs is "busy". Where does the app store any data
>
>You might not like it but you cannot have it any other way :)
>
>Fact: flash chip sectors takes long to erase (1-2 seconds)
>
>Fact: you need to erase to make room for new data
>
>Hence, if you need the app to do synchronous writing, it will need to
>wait.
>
>
> > time a task updating variables on the FS will block. The question is: How
> > long a block is acceptable? IMHO, anything more than a few hundred ms will
> > be unacceptable to a reasonable percentage of embedded applications. I 
> know
>
>Then you can't use flash chips in your embedded application :)
>
> > > > caching layer that will allow the transaction log to be put on 
> *another*
> > > > non-volatile medium if such is available in your system. The big 
> advantage
> > >
> > >Why would this be necessary ?
> >
> > To provide for 0 latency writes for tasks updating data values, when the
> > underlying fs is blocked and cannot accept any more writes for another
> > "few" (at the moment >40) seconds.
>
>So what happens when that gets full and need to be erased ? All you'd do
>is interleave the writes and postpone the problem a bit. If you mean that
>the transactional log will "never" get full and require erasing, then yes,
>that would work but I doubt the "never" constraint :)

That's why if 0 latency writes are important to a design, they must put 
this cache on a 0-erase-latency non-volatile medium like a battery backed 
RAM or FRAM.
Then a simple equation will help one size it for one's particular need, namely:

C_KB = size_of_nonvolatile_cache_device_required;
t1 = max_block_time_of_flash_FS_sec;
t2 = time_to_xfer_C_KB_to_flash_FS_sec;
NEW_KB_PER_SEC = max_new_data_generating_rate_KB_per_sec;


C_KB = (t1+t2) * NEW_KB_PER_SEC;

That's what the 0 latency write, transaction protected, embedded database 
project on the dev list is for.

Vipin

  reply	other threads:[~2001-07-07 12:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-21 10:54 safe flash filesystem Abraham vd Merwe
2001-06-21 13:43 ` Vipin Malik
2001-06-21 13:57   ` Abraham vd Merwe
2001-06-21 14:29     ` Vipin Malik
2001-06-21 14:35       ` Abraham vd Merwe
2001-06-21 15:05         ` Vipin Malik
2001-06-21 15:36           ` Chris Read
2001-06-21 15:09         ` Joakim Tjernlund
2001-06-21 15:34           ` Vipin Malik
2001-06-21 19:34             ` Joakim Tjernlund
2001-06-21 19:47             ` Joakim Tjernlund
2001-06-21 15:11         ` Herman Oosthuysen
2001-06-21 17:54           ` Tim Riker
2001-06-21 19:43             ` Vipin Malik
2001-06-21 19:35               ` Tim Riker
2001-06-21 19:56                 ` Vipin Malik
2001-06-21 21:17                   ` Kyle Harris
2001-07-03 23:53                     ` On the "safe filesystem" and write() topic Bjorn Wesen
2001-07-04 14:10                       ` Vipin Malik
2001-07-05 18:16                         ` Bjorn Wesen
2001-07-06 13:40                           ` Vipin Malik
2001-07-07  9:25                             ` Bjorn Wesen
2001-07-07 13:06                               ` Vipin Malik [this message]
2001-06-21 21:26         ` safe flash filesystem Russ Dill
2001-06-22  8:22           ` Abraham vd Merwe
     [not found]           ` <20010622102154.E1828@crystal.2d3d.co.za>
2001-06-22 17:23             ` Russ Dill
2001-06-25  7:45               ` Abraham vd Merwe
2001-06-25  7:59                 ` Russ Dill
2001-06-25 14:11                   ` Vipin Malik

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=5.1.0.14.0.20010707075247.00a67798@mail.spewey.com \
    --to=vipin@embeddedlinuxworks.com \
    --cc=bjorn.wesen@axis.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox