From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.broadpark.no ([217.13.4.2]) by canuck.infradead.org with esmtp (Exim 4.33 #1 (Red Hat Linux)) id 1Bkev7-0001A9-F5 for linux-mtd@lists.infradead.org; Wed, 14 Jul 2004 04:15:18 -0400 From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: David Woodhouse In-Reply-To: <1089759689.8822.18.camel@imladris.demon.co.uk> 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> <1089726079.6288.5.camel@famine> <1089759689.8822.18.camel@imladris.demon.co.uk> Content-Type: multipart/mixed; boundary="=-x+M80IMBpMTCa9/ENmkV" Message-Id: <1089792912.7607.22.camel@famine> Mime-Version: 1.0 Date: Wed, 14 Jul 2004 10:15:12 +0200 Cc: linux-mtd@lists.infradead.org, ecos-discuss@sources.redhat.com Subject: Re: JFFS2 eats memory List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --=-x+M80IMBpMTCa9/ENmkV Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Wed, 2004-07-14 at 01:01, David Woodhouse wrote: > On Tue, 2004-07-13 at 15:41 +0200, Øyvind Harboe wrote: > > After your walkthrough if the approach on IRC, I came up with this > > patch, which seems to take care of the problem. > > I can't work out what that's doing. Does it do something like this? Yes. - I made a small fix: update jeb->last_node - Ran some tests and it appears to do the job nicely on my rocket. -- Øyvind Harboe http://www.zylin.com --=-x+M80IMBpMTCa9/ENmkV Content-Disposition: attachment; filename=memfix.txt Content-Type: text/x-patch; name=memfix.txt; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: nodemgmt.c =================================================================== RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/nodemgmt.c,v retrieving revision 1.6 diff -w -u -r1.6 nodemgmt.c --- nodemgmt.c 11 Dec 2003 23:33:54 -0000 1.6 +++ nodemgmt.c 14 Jul 2004 08:12:21 -0000 @@ -549,6 +549,50 @@ printk(KERN_WARNING "Short write in obliterating obsoleted node at 0x%08x: %zd\n", ref_offset(ref), retlen); return; } + + /* Nodes which have been marked obsolete no longer need to be + associated with any inode. Remove them from the per-inode list */ + if (ref->next_in_ino) { + struct jffs2_inode_cache *ic; + struct jffs2_raw_node_ref **p; + + ic = jffs2_raw_ref_to_ic(ref); + for (p = &ic->nodes; (*p) != ref; p = &((*p)->next_in_ino)) + ; + + *p = ref->next_in_ino; + ref->next_in_ino = NULL; + } + + /* Merge with the next node in the physical list, if there is one + and if it's also obsolete */ + if (ref->next_phys && ref_obsolete(ref->next_phys)) { + struct jffs2_raw_node_ref *n = ref->next_phys; + + ref->__totlen += n->__totlen; + /* we don't need to check jeb->last_node */ + ref->next_phys = n->next_phys; + BUG_ON(n->next_in_ino); + jffs2_free_raw_node_ref(n); + } + + /* Also merge with the previous node in the list, if there is one + and it that one is obsolete */ + if (ref != jeb->first_node) { + struct jffs2_raw_node_ref *p = jeb->first_node; + + while (p->next_phys != ref) + p = p->next_phys; + + if (ref_obsolete(p)) { + p->__totlen += ref->__totlen; + if (jeb->last_node == ref) { + jeb->last_node = p; + } + p->next_phys = ref->next_phys; + jffs2_free_raw_node_ref(ref); + } + } } #if CONFIG_JFFS2_FS_DEBUG > 0 --=-x+M80IMBpMTCa9/ENmkV--