JFFS2 eats memory

Øyvind Harboe oyvind.harboe at zylin.com
Wed Jul 21 08:03:16 EDT 2004


On Wed, 2004-07-21 at 13:51, David Woodhouse wrote:
> On Wed, 2004-07-21 at 08:25 +0200, Øyvind Harboe wrote:
> 
> > in gc.c:
> 
> > -	241		if (!raw->next_in_ino) {
> 
> > -	251		ic = jffs2_raw_ref_to_ic(raw);
> 
> Hmmm. Surely you shouldn't be able to get to those in the case where
> gc_node is NULL? You should hit the condition at line 218 because
> jeb->user_size should be zero.
> 
> Remember, gc_node is the placemarker for the garbage-collector which is
> busily obsoleting every node in this block so that the block can be
> erased and returned to the free pool. If you were freeing a node, and
> there was no 'next' node when you did so, that must have meant you got
> to the end of the eraseblock, surely?
> 
> Obviously I'm wrong -- you have empirical evidence. But why?

I have no idea. It is easy to reproduce in the fashion I described and
this problem is complex enough that it takes a JFFS2 export a couple of
rounds in the debugger to sort out. At this point I think little would
be gained by me pursuing it.

But. What about my fix where I set jeb->gc_node to the previous element?
Isn't that a better solution in any case?

> PS. Will somebody please kick Beat Morf <beat.morf at duagon.ch> off the
> eCos list?

He will be punished at least. "autorespond = valid email address spack
ack support" :-)

-- 
Øyvind Harboe
http://www.zylin.com






More information about the linux-mtd mailing list