I am sure yaffs is not the problem. The overlayfs I use appears to cause the leak. I can see the same the problem if I use vfat insted of yaffs as upper fs. --pawel On Fri, Jun 12, 2015 at 8:10 AM, Pawel Jasinski wrote: > Hi Charles, > > first of all thanks for help! > > My original investigation went exactly this way. I suspected a process > holding open file descriptor. > However, my test files are test files created by me and not open by > any other process or overlayfs. > Just to rule out bug or whatever, I added a trace at the exit of > yaffs_rename to show i_nlink of the existing target. > > 1967 T(YAFFS_TRACE_OS, (TSTR("yaffs rename removing target > %d count: %d\n"), > 1968 target->obj_id, new_dentry->d_inode->i_nlink)); > > It always report count 0. > I will keep digging. > --pawel > > On Fri, Jun 12, 2015 at 12:55 AM, Charles Manning wrote: >> Hello Pawel >> >> Thank you for investigating this further. >> >> When you do rename with an existing target, the existing file will still >> exist while yaffs thinks the file is open. In the case of Linux, this means >> that yaffs still thinks there is an inode open for the file. >> >> The same sort of thing happens if you do something like: >> >> f = open("filename"...) >> unlink("filename"); >> >> read/write f can continue. >> >> >> The file will continue to exist and the file handles will still work (ie. >> you can continue to read/write the file). You obviously cannot open the file >> again because there is no directorym entry for the file. You can, however, >> still create new handles with dup() etc. >> >> However as soon as you close the last handle to the file it will be >> released. >> >> I cannot look at this for a few days, but if you could have a bit more of a >> look that would be great. >> >> Thanks >> >> Charles >> >> >> >> On Fri, Jun 12, 2015 at 9:57 AM, Pawel Jasinski >> wrote: >>> >>> hi, >>> >>> I have a linux 2.6.36 with yaffs and patches from openwrt. >>> The yaffs is mounted as upper in overlayfs. >>> So far so good. >>> Things appear ok as long as I simply remove files with rm (unlink). >>> Once I try to move (rename) the file where there is already an >>> existing file, the space occupied by existing file is not reclaimed. >>> >>> get some content into test1 >>> $ cp test1 test2 >>> $ mv test2 test1 >>> >>> I put kprintf all over the place and enabled yaffs log (+os). As far >>> as I can tell, the yaffs_rename is called and it does the job in terms >>> of yaffs. However the yaffs_evict_inode is not called after, so the >>> chunks are never deleted. >>> Rebooting brings the lost blocks back. I assume things get cleaned up >>> during mount. >>> >>> Perhaps someone recalls this issue from 2.6 days and can give me a hint. >>> At the moment I am looking at d_move_locked which is most likely not >>> interacting well with yaffs_rename. >>> >>> So far I tried: >>> 1. flushing the directory cache with: >>> echo 2 > /proc/sys/vm/drop_caches >>> which calls evict_inode on a lot of entries but not the one in question. >>> >>> 2. Check that the kernel calls evict_inode when I do the same operation on >>> FAT. >>> >>> 3. Look at git log of yaffs for a hint of a fix. >>> >>> >>> cheers, >>> --pawel >>> >>> _______________________________________________ >>> yaffs mailing list >>> yaffs@lists.aleph1.co.uk >>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs >> >>