This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: JFFS2 Garbage Collection Error?


> What I see is that on both the synthetic and real target the exact same
> behavior happens.  Everything works fine until the first time that
> jffs2_garbage_collect_dnode() gets called.  A few more calls down the
> stack and I take and exception caused by rb_remove_color dereferencing a
> null pointer.
> 
> Has anyone seen anything like this? 

I haven't, but admittedly most of my testing is under Linux. I suspect
it's a bug with my port of the BSD rbtree code to eCos, or a bug in
jffs2_add_full_dnode_to_inode() which only manifests itself in eCos for
some reason.

The function jffs2_garbage_collect_dnode() doesn't do anything special
-- it just overwrites some part of the file with the _same_ data as used
to be in that part of the file, to obsolete the original copy so we can
erase the block containing the original copy.

So given that it's a fairly safe bet it's an extent-list-management bug,
you should be able to trigger it fairly easily just be creating one file
in precisely the same manner as your test code does, then going back and
overwriting one range of data -- whichever range was being overwritten
by jffs2_g_c_dnode().

If you can reproduce this with CONFIG_JFFS2_FS_DEBUG=2, the debugging
spew will contain complete dumps of the rbtree before and after the
erroneous addition and it should all become fairly obvious.

>  If you are successfully using JFFS2, have you ever seen
> jffs2_garbage_collect_dnode() get called?

This would be called from jffs2_garbage_collect_pass(), which is called
just-in-time from jffs2_reserve_space() to make room for attempted
writes. You won't see it called until you've filled up your flash by
creating and deleting files, and then you'll probably see it called
quite a lot.

Under Linux, we have a background thread which will tend to free up some
space just _ahead_ of time, but we don't require threads for the eCos
build and that's not implemented. Copying background.c and making an
eCos version, dependent on having thread support configured in, is left
as a fairly simple exercise for the reader.

Erases are _also_ done from a separate thread (the generic kupdated
thread) under Linux, and directly from JFFS2 under eCos as you've
observed. That can probably be improved but ignore it for now since I
want to move it in Linux too.

-- 
dwmw2


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]