Re: [iPAQ] Battery Life, Flash Writing, etc...

jg@pa.dec.com said:
> Note we don't need compression on the fly: in fact, in operation, we
> believe PDA's are most likely to be storing already compressed data
> into flash (e.g. JPEG's from cameras, audio streams, etc.), so just
> being able to read executables and shared libraries from compressed
> form (paging out of compressed data) will go a long way: we don't want
> compression enabled by default (we believe that applications should
> give a hint to the file system whether it would be useful or not).
> Since doing compression twice eats batteries, we really want to avoid
> double compression scenarios.

For JFFS, you have compression on the fly or not at all. Nodes are
rewritten as the log recycles old space, so you have to decompress the old
node, merge in any changes made in subsequent writes to the area which it
covers, then recompress and write out a new node, before you can erase the
old node to make space.

You _have_ to recompress or the log will just keep expanding until the head
meets the tail and you have no more space to operate. Actually, it's
difficult to give formal proof that such won't happen even if you _do_
recompress, because the 'subsequent changes' may cause the area to compress
far less efficiently than it did in the original, and hence take up more
physical space.

We can get started just by giving ourselves a lot of 'slack' space to
accommodate such expansion, but I really do want formal proof of
correctness. There are some ideas floating about on how we could manage
that, but it's best discussed on the JFFS development list.

--
dwmw2