Some initial results: after making the suggested change, the lost blocks are found and the amount of space that is said to be in use with df is approximately the same as the amount indicated by du. I am going to run the tests for the rest of the week to see if there is a slow loss. I also notice that the corresponding code in the forward scan was also disabled: if (0 && (parent == dev->deletedDir || parent == dev->unlinkedDir)) { /* If it is unlinked at start up then it wants deleting */ in->deleted = 1; dev->nDeletedFiles++; } John. On Mon, 2005-12-19 at 07:02 +1300, Charles Manning wrote: > Thanx to the folk who have llooked into this problem recently. > > I will construct a test for this and see what happens. It looks like what > Mikhail has raised is likely on track. > > -- Charles > > > On Saturday 17 December 2005 12:05, Mikhail Ryleev wrote: > > I see exactly the same problem, and I think the bug is in > > yaffs_ScanBackwards routine. > > > > The solution that I have at this point is to delete the following lines in > > yaffs_ScanBackwards routine: > > > > ....... > > yaffs_AddObjectToDirectory(parent, in); > > > > #if 0 > > if ((parent == dev->deletedDir || > > parent == dev->unlinkedDir)) { > > /* If it is unlinked at start up then it wants deleting */ > > in->deleted = 1; > > } > > #endif > > > > if (oh->isShrink) { > > /* Mark the block as having a shrinkHeader */ > > bi->hasShrinkHeader = 1; > > } > > ....... > > > > Setting in->deleted to 1 here does not have much sense at least if > > this objects is in unlinked list. If you do that than the object gonna have > > both "unlinked" and "deleted" flags set and yaffs_DestroyObject does > > nothing to reclaim space. If you modify this code as directed then all > > files in "unlinked" state will be moved in "deleted" state after scan > > complete and they will be reclaimed at garbage collection time. > > > > I am not sure that this is a proper fix though, it might be a treatment for > > symptom and not the cause. I would like to have some feedback from guys who > > really understand what is going on here. > > > > M. > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs