Re: JFFS3 and RAM consumprion reincarnated

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Thu, 3 March 2005 11:09:12 +0000, Artem B. Bityuckiy wrote:
> 
> > 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 :-)

Ok, sorry.  -ENOTIME, didn't read all previous postings, just your
references.

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

Yup.  Thanks for checking, I was too lazy.

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

Not in English, no.  But a simple design is an indication of a simple
implementation - more robust, less buggy, pick your favorite
attribute.

> 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();
> 	}
> }

Almost.  Unless I misread Read_the_block_summary() and you mean "take
the list of erase blocks from ICP"

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

> 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.  Time
to code and test things.

Jörn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike