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
>