JFFS3 and RAM consumprion reincarnated

[Artem B. Bityuckiy]

On Fri, 2005-03-04 at 17:24 +0100, Jörn Engel wrote:
> Not in English, no.  But a simple design is an indication of a simple
> implementation - more robust, less buggy, pick your favorite
> attribute.
Simple and clear design is certainly of high priority. But again, I
afraid the performance will suffer too much.

> Almost.  Unless I misread Read_the_block_summary() and you mean "take
> the list of erase blocks from ICP"
ICP contains per-inode information. Physical nodes are placed
everywhere.
Summary node contains per-block information, i.e., one summary node
describes all the nodes in the current block. We suppose JFFS3 supports
summaries.

Consequently, Read_the_block_summary() means read the summary node, no
need to scan block.

> 
> > We risk to end up with extremely slow iget().
> 
> Hence, we should cache this.  Extremely slow iget() under memory
> pressure is fine, still much faster than OOM.  Without memory
> pressure, we'd have current performance.
Hmm. Do you know whether it possible to register JFFS2-specific "reap"
function ?

> 
> > But yes, as I wrote earlier and as you has affirmed, this is fairly simple 
> > and elegant idea. ICP is not needed here at all while summary nodes are 
> > obligatory. And this fits well to the idea of superblock which is 
> > distributed and encompasses summaries.
> 
> Well, I'd still store *some* information, namely the full list of
> erase blocks containing nodes.  Not sure if that is necessary, maybe
> you're right and we should get rid of this information as well. 
No need to create ICP to store this IMO.

> Time to code and test things.
I think it is a bit early. We need to discuss and agree on something.
Then document it and agree again. :-) If there are several approaches,
I'd like to design them all :-)
I'll try to gather all together and document this. I'd be happy to get
some help :=)

Furthermore, I'd like to discuss several extra ideas, e.g.:
*	Separate users writes and GC writes between different blocks.
*	Deletion direntries processing. It is far no good in JFFS3.


-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.