----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Anand Avati" <avati@xxxxxxxxxxx>, "Brian Foster" > <bfoster@xxxxxxxxxx>, "Raghavendra Bhat" <rabhat@xxxxxxxxxx> > 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" <pkarampu@xxxxxxxxxx> > >> To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Anand Avati" > >> <avati@xxxxxxxxxxx>, "Brian Foster" > >> <bfoster@xxxxxxxxxx>, "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, > >> "Raghavendra Bhat" <rabhat@xxxxxxxxxx> > >> 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@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
