sorry,I read you patch( http://review.gluster.org/14911),that fix the problem.Thanks very much.
2016-11-16 22:38 GMT+08:00 jin deng <cheneyden...@gmail.com>: > > > 2016-11-16 22:30 GMT+08:00 Soumya Koduri <skod...@redhat.com>: > >> >> >> On 11/16/2016 07:38 PM, jin deng wrote: >> >>> Thank you so much.Soumya,you make me more clear about the logic of the >>> code. >>> >>> I used to wonder the code was to handle the last resolve case.However i >>> followed >>> >>> the "nfs3_fh_resolve_entry_hard" and I thought it would get the ret == >>> -2 case and went >>> >>> into the "nfs3_lookup_op" branch,and finally call the >>> "nfs3_call_resume".Seems has >>> >>> no chance to call "nfs3_fh_resolve_entry_lookup_cbk" because it was a >>> LOOKUP >>> >>> operation.Am i wrong again? :-) >>> >> >> You are right :)...for LOOKUP fop, we go to "nfs3_call_resume" which is >> nfs3_lookup_resume and the callback is "nfs3svc_lookup_cbk" where in we are >> not updating cs->stbuf. But we seem to be constructing lookup reply >> (nfs3_lookup_reply) using 'buf' directly returned for the child entry >> instead of using cs->stbuf. Maybe that's the reason it was working well >> till now. >> FYI - there was an issue in the lookup logic code path which we fixed as >> part of http://review.gluster.org/14911 . I will not be surprised if >> there are any more lurking around :) >> > > hmm...seems still has a problem.As the "cs->hardresolved" has been set to > 1 in "nfs3_fh_resolve_inode_hard".The "nfs3_lookup_resume" callback will > not > get into the "nfs3svc_lookup_cbk".Instead,the "nfs3_lookup_resume" will > terminate at here as I thought: > > if (cs->hardresolved) { > stat = NFS3_OK; > nfs3_fh_build_child_fh (&cs->parent, &cs->stbuf, &newfh); > goto nfs3err; > } > > I wonder if this works fine because the NFS client always resolve the > parent first, not very sure. > > >> Thanks, >> Soumya >> >> >>> >>> >>> 2016-11-16 21:45 GMT+08:00 Soumya Koduri <skod...@redhat.com >>> <mailto:skod...@redhat.com>>: >>> >>> >>> >>> On 11/16/2016 06:38 PM, Pranith Kumar Karampuri wrote: >>> >>> Added people who know nfs code. >>> >>> On Wed, Nov 16, 2016 at 6:21 PM, jin deng >>> <cheneyden...@gmail.com <mailto:cheneyden...@gmail.com> >>> <mailto:cheneyden...@gmail.com <mailto:cheneyden...@gmail.com>>> >>> >>> wrote: >>> >>> Hi all, >>> I'm reading the code of 3.6.9 version and got a >>> question.And I'm >>> not very familiar with the code,so I have to confirm it(I >>> checked >>> the master branch,it's same with 3.6.9). >>> >>> The question is about the 'lookup' operation of NFS.And >>> i'm with >>> this code flow: >>> >>> nfs3_lookup (nfs3.c) ==> nfs3_fh_resolve_and_resume >>> ==> nfs3_fh_resolve_root ==> nfs3_fh_resolve_resume >>> ==> nfs3_fh_resolve_entry ==> nfs3_fh_resolve_entry_hard. >>> >>> Now enter the "nfs_entry_loc_fill" and return with -1 which >>> means >>> the "parent" not found,so we have to do hard resolve about >>> the >>> parent. After doing a hard resolve,we get into the callback >>> "nfs3_fh_resolve_inode_lookup_cbk".And the callback has the >>> following code: >>> >>> >>> memcpy (&cs->stbuf, buf, sizeof(*buf)); >>> >>> memcpy (&cs->postparent, buf, sizeof(*postparent)) >>> >>> >>> This must had been done (and required) in case if this was the last >>> entry(/inode) to be looked up >>> >>> >>> I think we've just done a parent resolve,how could we assign >>> the >>> parent result into the "stbuf" and "postparent".The later >>> two should >>> be the information of the child file/directory.Do i made a >>> misunderstand? >>> >>> >>> In case if it was not the last entry we fall through below code in >>> "nfs3_fh_resolve_inode_lookup_cbk" - >>> >>> if (cs->resolventry) >>> nfs3_fh_resolve_entry_hard (cs); >>> >>> Callback is "nfs3_fh_resolve_entry_lookup_cbk()" where in cs->stbuf >>> and cs->postparent get overridden with the values corresponding to >>> the child entry. >>> >>> Thanks, >>> Soumya >>> >>> >>> Thanks advance for your help. >>> >>> _______________________________________________ >>> Gluster-users mailing list >>> Gluster-users@gluster.org <mailto:Gluster-users@gluster.org> >>> <mailto:Gluster-users@gluster.org >>> <mailto:Gluster-users@gluster.org>> >>> http://www.gluster.org/mailman/listinfo/gluster-users >>> <http://www.gluster.org/mailman/listinfo/gluster-users> >>> <http://www.gluster.org/mailman/listinfo/gluster-users >>> <http://www.gluster.org/mailman/listinfo/gluster-users>> >>> >>> >>> >>> >>> -- >>> Pranith >>> >>> >>> >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://www.gluster.org/mailman/listinfo/gluster-users