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>