Re: [Yaffs] loosing space on rename with existing target

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: Pawel Jasinski
CC: YAFFS ML
Subject: Re: [Yaffs] loosing space on rename with existing target
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
>
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>