JFFS3 memory consumption

[Thomas Gleixner]

On Fri, 2005-01-28 at 08:45 +0000, Artem B. Bityuckiy wrote:
> But my original proposal assumed we agree with that and was about a bit 
> another thing. The question was: do we really want to distinguish between 
> pritine nodes and non-pristine nodes.

Yes.

> Recall for those who do not remeber JFFS2 internals: pristine node is that 
> node which contains PAGE_SIZE (4K) bytes of data. These nodes may quicly 
> satisfy read request - just unpack the node's data to the page provided by 
> upper layer. Non-pristine nodes are those nodes which contain fewer then 
> PAGE_SIZE bytes of data or they may contain 4K of data, but be partially 
> overlapped by newer node with more actual data.
> 
> My Idea is that having write-back cache a lot of writes will first go to 
> the cache, and we may just always write by 4K fractions. No more 
> not-pristine nodes. All nodes are now 4K or multiple of 4K.

I disagree. Are you really trying to tell me that _ALL_ nodes are 4K
size aligned ? Just look at your filesystem. 

> Adwantages:
> Simpler GC. Now we not need to merge non-pristine nodes. When Garbage 
> Collect one block, do not produce dirt in another block (because of 
> merging). GC is much faster. We do not need to iget() anymore when we meet 
> non-pristine node in GC.

It's not simpler, because you have to take care of synchronous
transactions.

> Drawbacks:
> Yes, if we are forced to do synchronose IO, we well waste more space. For 
> example, user does 1 byte transactions, we write 4K instead every time. 
> But is this so bad?

Yes, because it requires much more write/erase cycles and the
performance will be worse than the current JFFS2.

tglx