From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28131 invoked by alias); 13 Jul 2004 07:40:55 -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 28123 invoked from network); 13 Jul 2004 07:40:54 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org with SMTP; 13 Jul 2004 07:40:54 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1BkHuG-0002fr-00; Tue, 13 Jul 2004 09:40:52 +0200 Date: Tue, 13 Jul 2004 07:40:00 -0000 To: ?yvind Harboe Cc: ecos-discuss@sources.redhat.com Message-ID: <20040713074052.GO18802@lunn.ch> Mail-Followup-To: ?yvind Harboe , ecos-discuss@sources.redhat.com References: <1089643331.3951.42.camel@famine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089643331.3951.42.camel@famine> User-Agent: Mutt/1.5.6+20040523i From: Andrew Lunn Subject: Re: [ECOS] JFFS2 eats memory X-SW-Source: 2004-07/txt/msg00166.txt.bz2 On Mon, Jul 12, 2004 at 04:42:11PM +0200, ?yvind Harboe wrote: > This issue has been discussed before, and although I have a workaround, > I'd dearly like to have it put to bed since it is starting to cause > problems elsewhere in my application: > > - My code opens a file for writing with O_TRUNC set, performs > a single write call, closes the file. > - After closing the file, JFFS2 has eaten memory. > - With the attached modifcations to JFFS2, it "only" eats 24 bytes. > - If I unmount and remount JFFS2, no memory is "lost" and JFFS2 works > fine. > > Presumably when the raw nodes in the file fragement list are marked as > obsolete, they are no longer required, but are not freed. > > Q: Is this fundamentally impossible or a "bad idea" to fix? How much memory are we talking about here in this example? The cache is there for a reason, so i would not want to unconditionally disable it. At least you need some CDL to control between fat & fast and slow & slim. I would also suggest you consider extending the CYGNUM_FS_JFFS2_RAW_NODE_REF_CACHE_POOL_SIZE concept to the inode cache. You can then control the size of the cache. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss