[ECOS] JFFS2 eats memory

David Woodhouse dwmw2@infradead.org
Tue Jul 13 10:05:00 GMT 2004


On Tue, 2004-07-13 at 11:49 +0200, Øyvind Harboe wrote:
> Changing the size of jffs2_raw_node_ref does not help much, since the
> problem is that my system runs out of memory since it continously
> overwrites existing files, thus filling up the flash with obsoleted
> nodes.

It'll help in a lot of cases. You have a jffs2_raw_node_ref for _all_
data nodes which are physically present on the flash, whether the inodes
to which they belong are opened or not. There can be thousands of these.

In Linux we also use a different allocator, allocating these from
fixed-size slabs so there isn't an 8-byte overhead for each one. 

> I'm pretty sure the problem is in the file fragment list...

What's the problem? You say the problem goes away when you prune the
icache... that implies that there's nothing being _lost_, but you're
just objecting to the fact that your inode cache is doing any caching.

It's keeping the inode around for you in case you open it again
immediately, because it _knows_ the garbage collector tends to exhibit
that kind of behaviour. You made it stop doing that, and your problem
went away, right?

Can you join #mtd on irc.freenode.net?

> Thats a lot more than I want to attempt with my current knowledge about
> JFFS2. :-)

It's not about JFFS2. It's about eCos. The complex parts of the JFFS2
bits are in the core JFFS2 code which you're not expected to touch. IT's
the eCos wrapper around that core code which needs a rewrite :)

-- 
dwmw2


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



More information about the Ecos-discuss mailing list