Re: [Yaffs] power cycle during rm

On Sun, Jun 7, 2009 at 8:50 PM, Babrian Viktor<v@renyi.hu> 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 <v@renyi.hu>
>> 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.
>>
>> Thanks in advance,
>> Viktor Babrian
>>
>>
>> _______________________________________________
>> yaffs mailing list
>> yaffs@lists.aleph1.co.uk
>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>