----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkara...@redhat.com> > To: "Raghavendra Gowdappa" <rgowd...@redhat.com> > Cc: "Gluster Devel" <gluster-devel@gluster.org>, "Anand Avati" > <av...@gluster.org>, "Brian Foster" > <bfos...@redhat.com>, "Raghavendra Bhat" <rab...@redhat.com> > Sent: Friday, July 4, 2014 5:39:03 PM > Subject: Re: regarding inode_link/unlink > > > On 07/04/2014 04:28 PM, Raghavendra Gowdappa wrote: > > > > ----- Original Message ----- > >> From: "Pranith Kumar Karampuri" <pkara...@redhat.com> > >> To: "Gluster Devel" <gluster-devel@gluster.org>, "Anand Avati" > >> <av...@gluster.org>, "Brian Foster" > >> <bfos...@redhat.com>, "Raghavendra Gowdappa" <rgowd...@redhat.com>, > >> "Raghavendra Bhat" <rab...@redhat.com> > >> Sent: Friday, July 4, 2014 3:44:29 PM > >> Subject: regarding inode_link/unlink > >> > >> hi, > >> I have a doubt about when a particular dentry_unset thus > >> inode_unref on parent dir happens on fuse-bridge in gluster. > >> When a file is looked up for the first time fuse_entry_cbk does > >> 'inode_link' with parent-gfid/bname. Whenever an unlink/rmdir/(lookup > >> gives ENOENT) happens then corresponding inode unlink happens. The > >> question is, will the present set of operations lead to leaks: > >> 1) Mount 'M0' creates a file 'a' > >> 2) Mount 'M1' of same volume deletes file 'a' > >> > >> M0 never touches 'a' anymore. When will inode_unlink happen for such > >> cases? Will it lead to memory leaks? > > Kernel will eventually send forget (a) on M0 and that will cleanup the > > dentries and inode. Its equivalent to a file being looked up and never > > used again (deleting doesn't matter in this case). > Do you know the trigger points for that? When I do 'touch a' on the > mount point and leave the system like that, forget is not coming. > If I do unlink on the file then forget is coming.
I am not very familiar with how kernel manages its inodes. However, as Avati has mentioned in another mail, you can force kernel to send forgets by invalidating the inode. I think he has given enough details in another mail. > > Pranith > > > > > >> Pranith > >> > > _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel