JFFS3 and RAM consumprion reincarnated

[Artem B. Bityuckiy]

Dear Joern,

> I agree with tglx, your approach is complicated (aka horrible).  How
> about something much simpler:
Whel this is on of approaches I've already proposed :-)

> o The ICP is just a list of erase blocks.
> o For any non-obsolete node belonging to an inode, the containing
>   erase block number *must* be part of ICP.
> o If an erase block doesn't contain non-obsolute nodes for this inode,
>   its number *should* not be part of ICP.
> o The ICP *can* be stored in flash.
Ok.

> Advantages over current design:
> o Lower memory consumption, as we don't track individual nodes anymore.
Right.

> Advantages over your old ICP concept:
> o GC and write are simple.  They simply add the current eraseblock to
>   the ICP list, if it isn't part of it already.
Right.

> Disadvantages:
> o Whenever we need to check the full node list, we take a few more
>   indirections.
I'll elaborate your "whenever" - this is iget() call at most. The 
per-inode list might also be required when we have deals with 
deletion/deleted direntries.

> o Removal of erase blocks from the ICP list is done on lookup.
>   "Whoops, this erase block doesn't contain any of my nodes."
Right.

> Ultimate advantage: Design can be explained in less words. :)
I don't think this is so important :-)

Again:
> o Whenever we need to check the full node list, we take a few more
>   indirections.
Well, this might be serious disadvantage. Conceivably, there is a large 
file which is distributed over a lot of blocks. The iget() of the relating 
inode assumes:

for (all blocks relating to our inode)
{
	Read_the_block_summary();
	Identify_the_position_of_all_the_inode's_nodes();
	for (all the nodes found)
	{
		Read_the_node();
	}
}

We risk to end up with extremely slow iget().

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.

BTW, I assume that the technique we're talking about is applied *only* to 
inodes that aren't in the inode cache (i.e., iget() haven't been called 
for them yet). (Is there some term for them?). Those inodes that are in 
inode cache do not need this since they keep track of nodes in 
fragtree/dirent list.

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