[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS2 problems

On Thu, 26 February 2004 15:26:21 +0000, David Woodhouse wrote:
> On Thu, 2004-02-26 at 18:36 +0900, Shuichi Mitarai wrote: 
> > Yes, I agree to your idea. But can eraseblock have such a
> > data structure at the _end_ of the eraseblock? If possible,
> > I want to how you think about replacement of the structure.
> The structure is written out when our normal write activity brings us
> near the end of the eraseblock. Then we produce the 'checkpoint' for
> that block and write it to the end, before filing the eraseblock in
> question on the 'clean_list' and picking another free eraseblock to
> write to next.

Which should be a mount option, btw.  It is a space/mount time
trade-off and some people care more about space.  Apart from that,
this is the approach to choose (tm).

> > For example, considering the case where we must always store 
> > 100 picture datum of the each size of 80KB. How much ROM
> > size must be needed for that specification? I can't estimate
> > the ROM size for the current JFFS2 because 
> > (jffs2_sb_info*) c->free_size can't be used immediately without
> > GCing. So, I suggested defined fixed-size blocks. Actually,
> > this will lose the benefit of compression. But it's
> > important for me to estimate ROM size correctly before
> > implimenting applications.
> Why is it necessary that the space must be available immediately,
> without GCing? That doesn't seem normal. We might _always_ need to GC.

Looks like GC is the real problem.  Some folks here cared about safe
deletion of files, to keep secret temporary data secret.  But there is
absolutely no way of knowing when the old data gets GC'd.

Same here, if Shuichi knew that GC already happened or could block on
a syscall until it finally happens, he also knew the empty space on
the fs (ignoring compression, but that's a feature, not a bug).

Not sure if we really want that ability, though.

Another thing: fixed sized blocks.  They might really make sense for
uncompressed data.  Whenever we write data, we write 4k, compress
them, and store them in the flash.  No more problems of one small
chunk writing in the middle of another large chunk with some
interesting effects during GC.  Could remove some complexity from the
code, even though it would be hard to stay compatible. :)


He that composes himself is wiser than he that composes a book.
-- B. Franklin

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com