Hi Sachin,
We have evidence of requests being served from DRC, I believe, but will fix
issues. Wireshark traces could be helpful.
Thanks,
Matt
----- Original Message -----
> From: "Sachin C Punadikar" <psac...@in.ibm.com>
> To: "Ganesha Developers" <nfs-ganesha-devel@lists.sourceforge.net>
> Sent: Monday, December 12, 2016 8:36:57 AM
> Subject: [Nfs-ganesha-devel] Unable to serve request through DRC
>
>
>
> Hello All,
> I am bit new to Ganesha. Forgive me for long email.
>
> I wanted to make use of DRC code to understand its functionality. I have
> instrumented Ganesha code such that response to the initial request (which
> can be cached) gets dropped, so that there will be re-transmission of the
> request, and the request gets served from the DRC. I code change is as
> below:
> --- a/src/MainNFSD/nfs_worker_thread.c
> +++ b/src/MainNFSD/nfs_worker_thread.c
> @@ -1330,8 +1330,10 @@ void nfs_rpc_execute(request_data_t *reqdata)
>
> DISP_SLOCK(xprt);
>
> /* encoding the result on xdr output */
> - if (!svc_sendreply(xprt, &reqdata->r_u.req.svc,
> + if (!(reqdesc->dispatch_behaviour & CAN_BE_DUP) &&
> + !svc_sendreply(xprt, &reqdata->r_u.req.svc,
> reqdesc->xdr_encode_func,
> (caddr_t) res_nfs)) {
> LogDebug(COMPONENT_DISPATCH,
>
> When I use this code for creating a file from RHEL 7.2 client, via NFSv3
> mount, even if I wait for 15-20 minutes, client do not report successful
> file creation/nor a failure.
> I used "touch" command. Whereas the file gets created at the server side (as
> expected). The client keeps on re-transmitting the request and never reaches
> the DR cache.
> Further code study indicated that the hash-key, was different for every
> request, and hence, when it was a re-transmition, then it was not getting
> hit from the cache and it was treated as new request (and for new request,
> the response was dropped purposely). So in short it was never ending story.
> Am I doing something wrong ? It is a code issue or something else ?
>
> struct dupreq_entry {
> struct opr_rbtree_node rbt_k;
> ....
> ....
> uint64_t hk; /* hash key */
> };
> Current code assign the hash-key as below (function - nfs_dupreq_start):
> /* TI-RPC computed checksum */
> dk->hk = req->rq_cksum;
>
> If I change above code to make use of constant hash value, say 1, it works.
> But having hash value 1 is meaningless. As the DRC entries we storing are as
> per the client, making use of client address to calculate hash would be more
> meaningful (but not sure).
> My below code modification works.
> --- a/src/RPCAL/nfs_dupreq.c
> +++ b/src/RPCAL/nfs_dupreq.c
> @@ -974,7 +974,7 @@ dupreq_status_t nfs_dupreq_start(nfs_request_t *reqnfs,
> }
>
> /* TI-RPC computed checksum */
> - dk->hk = req->rq_cksum;
> + dk->hk = drc->d_u.tcp.hk; /* we have the hash readily available */
>
> dk->state = DUPREQ_START;
> dk->timestamp = time(NULL);
>
> Let me know whether above kind of hash key is correct or I should make use of
> xid to get hash value.
> Thanks in advance.
>
> with regards,
> Sachin Punadikar
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
