JFFS3 and RAM consumprion reincarnated
Artem B. Bityuckiy
dedekind at infradead.org
Tue Mar 1 11:28:36 EST 2005
I'd like to continue the JFFS3 RAM consumption discussion.
Please, take a glimpse at
and follow the conversation
to refresh your memory.
Well, I suppose the reader knows what are Summary and ICP. If no, follow
the links above.
We've stopped on the design like this: each inode has ICP which is stored
on flash. The ICP is being outdated by GC and users. Since it is
inefficient to rewrite new inode every time, we won't rewrite it but add
node_ref instead. Sometimes we'll flush ICP and free node_refs.
1. We have inode X with 10 nodes (node 1, node 2, ... node 10) and ICP
node which describes them. So far so good. On iget() call we read ICP and
have the inode built.
2. Suppose GC has moved node 1 of our inode. Its position has been
changed, so the relating ICP entry is obsolete now. In this case JFFS3
does not rewrite new ICP. Instesd, it allocates node_ref for node 1 and
keeps it in-core.
Now, on iget() call, we read ICP and the node 1's node_ref and this is
sufficient to build our inode.
Anologeously, if another nodes are moved, we just allocate more node_refs.
Sometimes, I don't specify when, we might rewrite old obsolete ICP and
free node_refs. And so on.
I think it makes sence to introduce JFFS3 parameter that limits the abount
of in-core RAM that JFFS3 might consume. Jets call this parameter
If JFFS3_MAXRAM = 0, we rewrite new ICP every time when any of its entry
If JFFS3_MAXRAM is very large, we have JFFS3 = JFFS2 in the memory
Artem B. Bityuckiy,
More information about the linux-mtd