From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22105 invoked by alias); 13 Jul 2004 10:05:41 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 22089 invoked from network); 13 Jul 2004 10:05:36 -0000 Received: from unknown (HELO pentafluge.infradead.org) (213.146.154.40) by sourceware.org with SMTP; 13 Jul 2004 10:05:36 -0000 Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with asmtp (Exim 4.33 #1 (Red Hat Linux)) id 1BkKAI-0001aq-QI; Tue, 13 Jul 2004 11:05:35 +0100 From: David Woodhouse To: =?ISO-8859-1?Q?=D8yvind?= Harboe Cc: ecos-discuss@sources.redhat.com In-Reply-To: <1089712151.5995.21.camel@famine> References: <1089643331.3951.42.camel@famine> <1089711000.2899.96.camel@hades.cambridge.redhat.com> <1089712151.5995.21.camel@famine> Content-Type: text/plain; charset=UTF-8 Message-Id: <1089713133.2899.117.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Date: Tue, 13 Jul 2004 10:05:00 -0000 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Subject: Re: [ECOS] JFFS2 eats memory X-SW-Source: 2004-07/txt/msg00174.txt.bz2 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