From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4202 invoked by alias); 15 Oct 2003 18:33:24 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 4195 invoked from network); 15 Oct 2003 18:33:23 -0000 Received: from unknown (HELO PH01SRV02.photuris.com) (141.150.26.4) by sources.redhat.com with SMTP; 15 Oct 2003 18:33:23 -0000 Received: by PH01SRV02.photuris.com with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Oct 2003 14:33:20 -0400 Message-ID: From: Doug Fraser To: 'Thomas Koeller' Cc: ecos-discuss@sources.redhat.com Date: Wed, 15 Oct 2003 18:33:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ECOS] Stress testing JFFS2 X-SW-Source: 2003-10/txt/msg00265.txt.bz2 It becomes an interesting issue when you are using the FLASH to store an actively updated database, which moves through the FLASH arena at some slow but consistent rate. Doug Fraser dfraser@photuris.com > -----Original Message----- > From: Thomas Koeller [mailto:thomas.koeller@baslerweb.com] > Sent: Wednesday, October 15, 2003 7:30 AM > To: David Woodhouse > Cc: ecos-discuss@sources.redhat.com; linux-mtd@lists.infradead.org > Subject: Re: [ECOS] Stress testing JFFS2 > > > Hi David, > > thanks for your quick response. > > > All correct. But you miss the observation that we also keep a > > raw_node_ref around for _obsolete_ nodes, which perhaps we > could avoid. > > In fact, we do this because the raw_node_ref is in a > singly-linked list, > > and it's going to be very inefficient to remove obsoleted nodes from > > that list when they become obsolete. > > I do not think this path leads anywhere I want to go. The flash size > was chosen to meet the expected storage requirements, which means that > at some point the flash will be filled with valid data and > consequently > there will be few obsoleted nodes. I expect this to be true for most > systems. > > > Omitting the 'totlen' field should be relatively simple if > you're not > > freeing obsolete refs. Observe that in 99% of cases, it's true that > > > > ref->totlen == ref_offset(ref->next_phys) - ref_offset(ref) > > > > Make it 100% and make me believe it, and you can remove > totlen from the > > structure. > > > > I will consider that. > > tk > -------------------------------------------------- > > Thomas Koeller, Software Development > > Basler Vision Technologies > An der Strusbek 60-62 > 22926 Ahrensburg > Germany > > Tel +49 (4102) 463-162 > Fax +49 (4102) 463-239 > > mailto:thomas.koeller@baslerweb.com > http://www.baslerweb.com > > ============================== > > > -- > Before posting, please read the FAQ: > http://sources.redhat.com/fom/ecos > and search the list archive: http://sources.redhat.com/ml/ecos-discuss > -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss