[Gluster-users] question about nfs lookup result

[jin deng]

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/432fbc47/attachment.html>