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 eats memory


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


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