From v@renyi.hu Thu Jun 11 22:31:19 2009 Received: from mirror.math-inst.hu ([193.224.79.10]) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MErrh-0008Uk-BO for yaffs@lists.aleph1.co.uk; Thu, 11 Jun 2009 22:31:19 +0100 Received: from hexagon.math-inst.hu ([193.224.79.1]) by mirror.math-inst.hu with esmtps(TLSv1:AES256-SHA:256) (Exim) from id 1MErrd-0002g2-UY; Thu, 11 Jun 2009 23:31:13 +0200 Received: from v (helo=localhost) by hexagon.math-inst.hu with local-esmtp (Exim) id 1MErrd-0001k6-RG from ; Thu, 11 Jun 2009 23:31:13 +0200 Date: Thu, 11 Jun 2009 23:31:13 +0200 (CEST) From: Babrian Viktor X-X-Sender: v@hexagon.math-inst.hu To: Charles Manning In-Reply-To: <200906091220.31660.manningc2@actrix.gen.nz> Message-ID: References: <200906091111.54886.manningc2@actrix.gen.nz> <200906091122.31139.manningc2@actrix.gen.nz> <200906091220.31660.manningc2@actrix.gen.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SPF: X-SA-Exim-Connect-IP: 193.224.79.10 X-SA-Exim-Mail-From: v@renyi.hu X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: yaffs@lists.aleph1.co.uk Subject: Re: [Yaffs] power cycle during rm X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:31:20 -0000 It does work (first tests are OK). I will keep you informed if any failures come up during testing. Thanks for the work, your help is very much appreciated. Viktor Babrian On Tue, 9 Jun 2009, Charles Manning wrote: > Date: Tue, 9 Jun 2009 12:20:31 +1200 > From: Charles Manning > To: yaffs@lists.aleph1.co.uk > Cc: Babrian Viktor > Subject: Re: [Yaffs] power cycle during rm > > Please try the fix in cvs > > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_guts.c?r1=1.84&r2=1.85 > > and see if that works. > > Thanks > > -- Charles > > On Tuesday 09 June 2009 11:22:31 Charles Manning wrote: >> On Tuesday 09 June 2009 11:11:54 Charles Manning wrote: >>> Hi All >>> >>> I'm looking at fixing the root problem, but for now you can modify the >>> line maxCopies = (wholeBlock) ? dev->nChunksPerBlock : 10; >>> to >>> maxCopies = (1 || wholeBlock) ? dev->nChunksPerBlock : 10; >>> >>> That will force a whole block gc. >> >> or even simpler... Set >> wholeBlock = 1; >> near the top of yaffs_GarbageCollectBlock(); >> >>> I would not force agressive gc as that causes more impact. >>> >>> -- CHarles >>> >>> On Monday 08 June 2009 15:05:05 Rong Shen wrote: >>>> On Sun, Jun 7, 2009 at 8:50 PM, Babrian Viktor wrote: >>>>> Hi again, >>>>> >>>>> my last questions: >>>>> - Is it OK to use aggressive garbage collection only? It cleanly >>>>> solves the issue for me. (my understanding is that it might be slower >>>>> but it won't do any harm) >>>>> - is it possible that the root cause of the problem is in some >>>>> underlaying layer (e.g. nand driver?) Under what circumstances can it >>>>> happen that the >>>> >>>> It looks more like a yaffs2 bug as you have pointed out. softDeletions >>>> shouldn't be subtracted from nFreeChunks if the block is not fully >>>> claimed. >>>> >>>>> softDeletions of a block gets to the maximum value? Can an >>>>> interrupted erase >>>> >>>> Maximum values, i.e. number of chunks (pages) per block gets maximum, >>>> in your case 64, when all chunks are soft deleted. >>>> >>>>> cause this? And whose responsibility is it to ensure that this does >>>>> not >>>> >>>> hmmm... >>>> >>>>> happen? Is it a yaffs issue or nand flash driver issue? >>>>> >>>>> Thanks, >>>>> Viktor Babrian >>>> >>>> Rong >>>> >>>>> On Fri, 29 May 2009, Babrian Viktor wrote: >>>>>> Date: Fri, 29 May 2009 16:25:28 +0200 (CEST) >>>>>> From: Babrian Viktor >>>>>> To: yaffs@lists.aleph1.co.uk >>>>>> Subject: Re: [Yaffs] power cycle during rm >>>>>> >>>>>> Hi, >>>>>> >>>>>> the reason why yaffs_GarbageCollectBlock() performs the row: >>>>>> dev->nFreeChunks -= bi->softDeletions; >>>>>> 7 times for each block is that yaffs_GarbageCollectBlock() is called >>>>>> with wholeBlock = 0 and therefore it deals with only 10 chunks of >>>>>> the block every time it is called (maxCopies = (wholeBlock) ? >>>>>> dev->nChunksPerBlock : 10). WHen deleting the last chunk of the >>>>>> block, the block is marked dirty and it gets out from the >>>>>> 'collecting' state and from that point >>>>>> yaffs_GarbageCollectBlock() is not called anymore with that given >>>>>> blocknumber. There are 64 chunks in each block and 64/10 gives 7. >>>>>> Now something is obviously wrong here. >>>>>> There are several solutions I see but I do not know the sideeffects >>>>>> of. Calling yaffs_GarbageCollectBlock() with wholeBlock = 1 only >>>>>> seems to solve the situation but there must be better solution than >>>>>> that. Performing the subtraction of bi->softDeletions only at the >>>>>> end of the function (when the block is not in collecting state) >>>>>> could also work but it is unclear to me if it leads to unconsistency >>>>>> or anything. I also do not know why the softDeletions of the given >>>>>> block is 64 - does that seem correct anyway? >>>>>> >>>>>> Please at least confirm whether this hack is OK - I need to make >>>>>> file operations as reliable as possible. Any other solutions are >>>>>> welcome of course. >