Re: [Gluster-devel] triggers for sending inode forgets
On Fri, Jul 4, 2014 at 8:17 PM, Pranith Kumar Karampuri 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
Re: [Gluster-devel] triggers for sending inode forgets
On 07/05/2014 08:17 AM, Anand Avati wrote: On Fri, Jul 4, 2014 at 7:03 PM, Pranith Kumar Karampuri 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
On Fri, Jul 4, 2014 at 7:03 PM, Pranith Kumar Karampuri 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 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
