4k-aligned nodes

Guys,

while giving a presentation about mtd/jffs2, an interesting idea
popped up.  Might be old.  If it is, please tell me to shut up.


Problem:
GC runs into many interesting corner-cases when collecting nodes that
were partially obsoleted by smaller nodes, etc.  Most notably is this
scenario:

Node 1: 1234567890abcdef1234567890abcdef
Node 2:                12
Node 3: 1234567890abcde
Node 4:                  234567890abcdef

Node 1 is old and contains two copies of non-compressable data.  With
zlib, the two copies are detected and the compressed data basically
has the size of one of the two copies.

Node 2 overwrites some bytes of node 1 right where both copies are
concatenated.

When GC has to copy parts of node 1, it may create two nodes 3 and 4,
that each contain one copy of non-compressable data.  Each of them has
roughly the same size as node 1, so both of them have twice the size.
GC didn't shrink flash footprint, bad.


Solution:
GC always tries to write out 4k-aligned nodes with 4k of uncompressed
data.

This also causes GC to run into corner-cases and occasionally use more
flash footprint than original data.  But in the long run, it should
cause data to be in the most efficient format on-flash.


Jörn

-- 
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]