JFFS3 memory consumption

[Artem B. Bityuckiy]

> I'm not sure I understand the difference.  In case 1) are you
> suggesting keeping the ICP like data in the summary nodes?
>
> I think the ICP's are a great idea.

Will try to express what I think.

So, we have summaries at the end of each block. Imagine an user has issued 
the open() call for some file. This means, that the VFS will invoke the 
JFFS3 inode iget() operation. The iget() is supposed to build the file's 
fragtree in order to be able to quickly read any file's data.

Obviously, to build the inode in the iget() we must know the positions of 
all the inode's nodes. In JFFS2 it is simply done by means of keeping the 
in-core objects for each node and having the per-inode lists. We do not 
want this, we want to save RAM.

How may we build the inode in the iget() operation?

1. For each inode we keep the in-core a list of block numbers (let's call 
this list the "inode_blocks list"). These are those blocks, which have at 
least one node belonging to our inode (the inode we are trying to build). 
Thus, to build the inode, we need:

for each block in the "inode_blocks list"
{
	read the block's summary node;
	find all nodes belonging to our inode in the summary;
}

If the inode's nodes are scattered over many blocks, this will quite slow;

But we may do the following optimizations:

A. Have special GC strategy to put (or try to put) nodes belonging to the 
same inode to the same blocks. Thus we may keep the number of blocks where 
the inode's nodes are scattered relatively small.

B. The summary entries in the summary nodes are sorted by the node offset. 
But when we are searching for the node which belongs to the specific 
inode, we would like to have the summary entries sorted by the inode 
number (then we may use quick binary search algorithm). So we may store in 
summary both physical offset-sorted entries and inode number-sorted 
entries. Possibly, the physical offset sorting is not really needed (the 
GC will just move nodes in another order).

So, having these both optimizations, we may keep the iget() operation fast 
enough.

2. ICP... The alternative is using ICP. ICP contains the ICP entries in 
its body. These entries describe all the nodes of our inode. Thus, for 
each inode, we may keep in-core only the inode's ICP offset. And when we 
need to build the inode in the iget() call, we need just to read the 
corresponding ICP, and that's all.

The problem here is that ICP contains the physical offsets of nodes. But 
the GC works and moves nodes brom one block to another, changing their 
offsets. And we need to often update ICPs - even for static RO files.

Thoughts?

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