[Gluster-users] question about nfs lookup result

jin deng cheneydeng88 at gmail.com
Wed Nov 16 14:47:01 UTC 2016


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 <cheneydeng88 at gmail.com>:

>
>
> 2016-11-16 22:30 GMT+08:00 Soumya Koduri <skoduri at 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 <skoduri at redhat.com
>>> <mailto:skoduri at 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
>>>         <cheneydeng88 at gmail.com <mailto:cheneydeng88 at gmail.com>
>>>         <mailto:cheneydeng88 at gmail.com <mailto:cheneydeng88 at 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 at gluster.org <mailto:Gluster-users at gluster.org>
>>>         <mailto:Gluster-users at gluster.org
>>>         <mailto:Gluster-users at 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
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161116/14c4d2b4/attachment.html>


More information about the Gluster-users mailing list