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