[RFC] Volatile data device vor jffs2

[RFC] Volatile data device vor jffs2

[Jörn Engel]

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

Re: [RFC] Volatile data device vor jffs2

[David Woodhouse]

On Sat, 2004-07-31 at 15:59 +0200, Jörn Engel wrote:
> 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.

I wouldn't do it like this -- why have a separate nvram device with
JFFS2 nodes in it, when we could just use the page cache and inode
cache. It's going to be _very_ hard to get fsync() et al right if we
implement our own caching.

The reason this hasn't been done is because it requires space
reservations, and that's not trivial. You have to ensure that you have
enough free flash space to make room for everything that's currently
outstanding in the cache. It shouldn't be _that_ hard though.

Doing this right should fix the problem you describe, of extremly
short-lived files hitting the medium when ideally they wouldn't ever get
written out. It would also help a lot with coalescing frequent short
writes to log files into larger nodes, and it would help us with
implementing shared writable mmap too.

-- 
dwmw2

Re: [RFC] Volatile data device vor jffs2

[Jörn Engel]

On Sun, 1 August 2004 13:33:01 +0100, David Woodhouse wrote:
> On Sat, 2004-07-31 at 15:59 +0200, Jörn Engel wrote:
> > 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.
> 
> I wouldn't do it like this -- why have a separate nvram device with
> JFFS2 nodes in it, when we could just use the page cache and inode
> cache. It's going to be _very_ hard to get fsync() et al right if we
> implement our own caching.

Your approach doesn't always work for me because sometimes people care
a lot about the last log entries.  They need to be inside a
non-volatile medium, either nvram or flash.  Unless you want to move
the page cache to nvram... ;)

Also, fsync can just do the same as sync.  If the helper device is
nvram, nothing at all.  If it's dram, flush it all to flash.

> The reason this hasn't been done is because it requires space
> reservations, and that's not trivial. You have to ensure that you have
> enough free flash space to make room for everything that's currently
> outstanding in the cache. It shouldn't be _that_ hard though.
>
> Doing this right should fix the problem you describe, of extremly
> short-lived files hitting the medium when ideally they wouldn't ever get
> written out. It would also help a lot with coalescing frequent short
> writes to log files into larger nodes, and it would help us with
> implementing shared writable mmap too.

All these problems should be fixed with my approach as well.  Plus it
is trivial to switch from dram to nvram if customers care.  And I
know customers that might ;)

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra

Re: [RFC] Volatile data device vor jffs2

[Wolfgang Denk]

In message <20040802170824.GC26115@wohnheim.fh-wedel.de> you wrote:
>
> Your approach doesn't always work for me because sometimes people care
> a lot about the last log entries.  They need to be inside a
> non-volatile medium, either nvram or flash.  Unless you want to move
> the page cache to nvram... ;)

Did you consider using oramfs? See http://pramfs.sourceforge.net/


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Of all the things I've lost, I miss my mind the most.

Re: [RFC] Volatile data device vor jffs2

[Jörn Engel]

On Mon, 2 August 2004 19:14:57 +0200, Wolfgang Denk wrote:
> In message <20040802170824.GC26115@wohnheim.fh-wedel.de> you wrote:
> >
> > Your approach doesn't always work for me because sometimes people care
> > a lot about the last log entries.  They need to be inside a
> > non-volatile medium, either nvram or flash.  Unless you want to move
> > the page cache to nvram... ;)
> 
> Did you consider using oramfs? See http://pramfs.sourceforge.net/

We already have something similar.  People have to sort their data and
send some to one fs, other to the other fs.  Prone to errors, static,
ugly code, etc.

Jffs2 would be able to do the sorting transparently.

Jörn

-- 
People will accept your ideas much more readily if you tell them
that Benjamin Franklin said it first.
-- unknown

Re: [RFC] Volatile data device vor jffs2

[Dermot McGahon]

On Sat, 31 Jul 2004 15:59:55 +0200, Jörn Engel  
<joern@wohnheim.fh-wedel.de> wrote:

> 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.

[-]

> Comments?

Well, it still needs to be flushed to something non-volatile at
some point.

You can vary the time between flushes. It depends on how valuable
that data is to you. With an approach such as this you are really
deciding how big of a window for data loss you are willing to put
up with.

The approach I took while doing this a couple of years ago was not
to erase blocks until absolutely necessary and then do all the
garbage collection/file system reorganisation once. This took time
to do though, was suitable for the device in question (a KVM), but
possibly not for a general filesystem.


Dermot.
--

Re: [RFC] Volatile data device vor jffs2

[Jörn Engel]

On Wed, 4 August 2004 09:55:41 +0100, Dermot McGahon wrote:
> 
> >Comments?
> 
> Well, it still needs to be flushed to something non-volatile at
> some point.

With a DRAM based device, yes.

> You can vary the time between flushes. It depends on how valuable
> that data is to you. With an approach such as this you are really
> deciding how big of a window for data loss you are willing to put
> up with.
> 
> The approach I took while doing this a couple of years ago was not
> to erase blocks until absolutely necessary and then do all the
> garbage collection/file system reorganisation once. This took time
> to do though, was suitable for the device in question (a KVM), but
> possibly not for a general filesystem.

That can be moved to a different thread, as already the case.  Except
for high-throughput write situations, it should be unnoticed by the
user.

Jörn

-- 
The grand essentials of happiness are: something to do, something to
love, and something to hope for.
-- Allan K. Chalmers