[Gluster-devel] triggers for sending inode forgets

[Anand Avati]

On Fri, Jul 4, 2014 at 8:17 PM, Pranith Kumar Karampuri <pkarampu at redhat.com
> wrote:

>
> On 07/05/2014 08:17 AM, Anand Avati wrote:
>
>
>
>
> On Fri, Jul 4, 2014 at 7:03 PM, Pranith Kumar Karampuri <
> pkarampu at redhat.com> wrote:
>
>> hi,
>>     I work on glusterfs and was debugging a memory leak. Need your help
>> in figuring out if something is done properly or not.
>> When a file is looked up for the first time in gluster through fuse,
>> gluster remembers the parent-inode, basename for that inode. Whenever an
>> unlink/rmdir/(lookup gives ENOENT) happens then corresponding forgetting of
>> parent-inode, basename happens.
>
>
>  This is because of the path resolver explicitly calls d_invalidate() on
> a dentry when d_revalidate() fails on it.
>
>  In all other cases it relies on fuse to send forget of an inode to
>> release these associations. I was wondering what are the trigger points for
>> sending forgets by fuse.
>>
>> Lets say M0, M1 are fuse mounts of same volume.
>> 1) Mount 'M0' creates a file 'a'
>> 2) Mount 'M1' of deletes file 'a'
>>
>> M0 never touches 'a' anymore. Will a forget be sent on inode of 'a'? If
>> yes when?
>>
>
>  Really depends on when the memory manager decides to start reclaiming
> memory from dcache due to memory pressure. If the system is not under
> memory pressure, and if the stale dentry is never encountered by the path
> resolver, the inode may never receive a forget. To keep a tight utilization
> limit on the inode/dcache, you will have to proactively fuse_notify_inval_entry
> on old/deleted files.
>
> Thanks for this info Avati. I see that in fuse-bridge for glusterfs there
> is a setxattr interface to do that. Is that what you are referring to?
>

In glusterfs fuse-bridge.c:fuse_invalidate_entry() is the function you want
to look at. The setxattr() interface is just for testing the functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140704/7cf4e0b0/attachment.html>