From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4711 invoked by alias); 13 Jul 2004 10:39:25 -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 4703 invoked from network); 13 Jul 2004 10:39:23 -0000 Received: from unknown (HELO mail.broadpark.no) (217.13.4.2) by sourceware.org with SMTP; 13 Jul 2004 10:39:23 -0000 Received: from famine (217-13-20-38.dd.nextgentel.com [217.13.20.38]) by mail.broadpark.no (Postfix) with ESMTP id 617342575; Tue, 13 Jul 2004 12:39:53 +0200 (MEST) From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: David Woodhouse Cc: ecos-discuss@sources.redhat.com In-Reply-To: <1089713133.2899.117.camel@hades.cambridge.redhat.com> References: <1089643331.3951.42.camel@famine> <1089711000.2899.96.camel@hades.cambridge.redhat.com> <1089712151.5995.21.camel@famine> <1089713133.2899.117.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1089715162.5995.37.camel@famine> Mime-Version: 1.0 Date: Tue, 13 Jul 2004 10:39:00 -0000 Content-Transfer-Encoding: 8bit Subject: Re: [ECOS] JFFS2 eats memory X-SW-Source: 2004-07/txt/msg00176.txt.bz2 On Tue, 2004-07-13 at 12:05, David Woodhouse wrote: > 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. When I say that reducing size does not "help", I mean that the problem with memory usage constantly increasing persits. It just takes a bit longer, e.g. my system falls over in 4 days instead of 1, which in my case makes no difference. > > > I'm pretty sure the problem is in the file fragment list... > > What's the problem? I'd like to take this oportunity to say that I'm trying to address this problem because I need to, not because my eCos/JFFS2 knowledge is up to the task. > You say the problem goes away when you prune the > icache... My problem *almost* goes away with the icache_evict() change. > 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? No, it almost went away. 24 bytes is still lost every time I overwrite/delete a file > Can you join #mtd on irc.freenode.net? I took it for a quick spin, but got some error messages. Perhaps some firewall issues, etc. I'm not familiar with IRC. > > 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 :) I see. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss