Re: [Yaffs] power cycle during rm

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Babrian Viktor
Date:  
To: Charles Manning
CC: yaffs
Subject: Re: [Yaffs] power cycle during rm
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:
> 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:
>>>>>> 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.
>