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 
softDeletions of a block gets to the maximum value? Can an interrupted 
erase cause this? And whose responsibility is it to ensure that this does 
not happen? Is it a yaffs issue or nand flash driver issue?

Thanks,
Viktor Babrian

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
>