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
<
pawel.jasinski@gmail.com> 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 <cdhmanning@gmail.com> 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 <pawel.jasinski@gmail.com>
>> 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
>>
>>
(text/plain)