JFFS3 memory consumption

[Thomas Gleixner]

On Mon, 2005-01-31 at 18:05 +0000, Artem B. Bityuckiy wrote:
> Will try to express what I think.
> 
> 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.

This might turn out to be a GC nightmare. Every update to a file might
result in shuffling tons of nodes around or at least trying to do so.

Keep it simple.

> 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.

Not only GC makes this necessary, every write to a file too. 

> Thoughts?

I'm not sure which of the mechanisms will provide us more horror. My
guess is ICP. The summary method is definitely less performant, but I
think therefor less complicated to handle. So we trade performance for
simplicity, which makes more sense for me than the other way round.

tglx