[RFC] Volatile data device vor jffs2

Jörn Engel joern at wohnheim.fh-wedel.de
Sat Jul 31 09:59:55 EDT 2004


This is still just a whacky idea but might fit well into other
unfinished plans for jffs2.


1. With flash storage, life time depends on the total amount of data
written to it.  Usual calculation is this:

              erase cycles * flash size
write speed = -------------------------
              lifetime

Depending on flash size, necessary lifetime and guaranteed erase
cycles of the flash, we operate somewhere in the area of 10kB/s.  Not
much.


2. Application developers have a hard time not to exceed such a limit.


Combine 1 and 2 and you have a problem.  Usual solution is to make
life harder on the application developers, but they have a natural
resistance and controlling them is Not Fun.  So here is another
approach.


a) Jffs2 has two erase blocks open for writing.  One is used
exclusively for garbage collection, the other exclusively for writing
new data.  This is an old idea.

b) Jffs2 has simultaneous access to two devices, one of which is used
exclusively for writing new data.  I call that one the "volatile"
device.

c) The volatile device is either ram based or nvram based.

With a ram based volatile device, there is danger of data loss, so
garbage collection would have to be forced from time to time, similar
to the current wbuf approach for nand.

Either way, a script like the one below will not kill your flash in a
few days:

while true; do echo foo > foo; rm foo; done


Anticipated question:  Why is this a good idea?  Shouldn't application
developers be taught, never to do this in the first place?

Sometimes code similar to the script above is needed.  Think of a
trace where you're only interested in the last 1k or so of data.  With
such a requirement, application developers would have to seperate
their data between flash and nvram devices.  This adds complexity.

If highly volatile and mostly static data (and anything in between)
can be treated the same, application code is nicely abstracted from
hardware details that should be left to the kernel.


Comments?

Jörn

-- 
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra




More information about the linux-mtd mailing list