[Gluster-devel] triggers for sending inode forgets

2014-07-04 Thread Pranith Kumar Karampuri

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. 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?


Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] triggers for sending inode forgets

2014-07-04 Thread Pranith Kumar Karampuri


On 07/05/2014 08:17 AM, Anand Avati wrote:




On Fri, Jul 4, 2014 at 7:03 PM, Pranith Kumar Karampuri 
pkara...@redhat.com mailto:pkara...@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?


Pranith


Thanks


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] triggers for sending inode forgets

2014-07-04 Thread Anand Avati
On Fri, Jul 4, 2014 at 8:17 PM, Pranith Kumar Karampuri pkara...@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 
 pkara...@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.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel