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
next prev parent 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