[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