Real-time flash simulator

[Jörn Engel]

On Fri, 22 June 2007 12:11:29 +0200, Martin Däumler wrote:
> 
> that is right! The idea is to use a (not specified) file system which 
> performs in-place updates on top of this layer. This layer should map
> logical to physical erase units. So, wear-levelling possibly could be
> used to "displace" garbage collection. The goal is to decrase latency
> and above all make it more deterministic.

Sounds just like FAT on smartmedia.  Worst case latency is both
deterministic and low.  Random writes of small blocks are also
prohibitively slow.  Works great when writing few large files, like jpg
images in digital cameras.

> But please note that is just one theoretical idea to make a flash file
> system real-time capable. Indeed, other approaches and file systems like
> LogFS has to be investigated further for this purpose too.
> 
> It seems the development of a real-time flash file system is still in
> the fledgling stages, hence I asked here for a flash simulator to make
> work easier.

I guess the first thing you need to do is define what real-time actually
means.  In particular you need to define the following:
o Maximal latency for single read.
o Maximal latency for single write.
o Maximal throughput for reads.
o Maximal throughput for writes.
o Read behaviour (random bytes from random files, sequential, etc.)
o Write behaviour (dito)
o Acceptable rate of higher latency reads/writes.

Once you have this, it is possible to determine whether some storage
stack (filesystem, middle layers, hardware) can fulfill your
requirements, or how it would need to be changed to do so.

Alternatively you can go the other way and take a given storage stack,
trying to determine the characteristics of it.

Jörn

-- 
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca