Hi,
I have 2 questions about the kernel rpc implementation.
1. What are the return codes (from rpc_call) and their meanings (or where
could I find that, I found that looking at the code itself was really hard).
2. Is it possible to know at what point the rpc call failed ? (from within the
rpc_task struct, to determine whether the caller couldn't send or it didn't get
a response).
About lock.
3. When the client think it has a lock on a nfs file, but the server thinks the
client hasn't, what happens ? (because I think that sometimes you have to chose
between that and the reverse, the client think it hasn't a lock the server
thinks it has).
Thanks.
Pat
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Patrice DUMAS <[email protected]> writes:
> Hi, I have 2 questions about the kernel rpc implementation.
> 1. What are the return codes (from rpc_call) and their meanings
> (or where could I find that, I found that looking at the
> code itself was really hard).
For an ordinary synchronous call, rpc_call() returns the value of
task->tk_status upon exit.
If the call could not be made, then that value will reflect an error
code, usually EINTR (although for 'soft' RPC calls, the error EIO will
be returned if a major timeout occurred).
If the call was made, then the value is set by the XDR decode entry
(see the macro rpcproc_decode(clnt, task->tk_msg.rpc_proc)) if it
exists in the 'struct rpc_procinfo' table.
If the server is not expected to return a value, then the
corresponding XDR decode entry should be NULL, and task->tk_status
should normally be zero upon rpc_call exit.
> 2. Is it possible to know at what point the rpc call failed ?
> (from within the rpc_task struct, to determine whether the
> caller couldn't send or it didn't get a response).
Only makes sense for 'soft' RPC calls, and in that case you get an EIO.
> 3. When the client think it has a lock on a nfs file, but the
> server thinks the client hasn't, what happens ?
File corruption is possible, and the server will return
'NLM_LCK_DENIED_NOLOCKS' when the client tries to unlock.
Cheers,
Trond
Hi,
Thanks for your reply.
> If the call could not be made, then that value will reflect an error
> code, usually EINTR (although for 'soft' RPC calls, the error EIO will
> be returned if a major timeout occurred).
....
> Only makes sense for 'soft' RPC calls, and in that case you get an EIO.
In case of an asynchronous call, is there such a difference between 'soft' and
'hard' rpc calls too ?
I haven't seen anywhere what was the kind of rpc call of the server side lockd.
Is it hard by default ?
Pat
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Patrice DUMAS <[email protected]> writes:
> In case of an asynchronous call, is there such a difference
> between 'soft' and 'hard' rpc calls too ?
Yes. 'hard' RPC calls will retry forever, and soft calls, will set
task->tk_status to EIO on a major timeout. This goes for both
synchronous and asynchronous calls.
> I haven't seen anywhere what was the kind of rpc call of the
> server side lockd. Is it hard by default ?
You need to set the flag clnt->cl_soft in order to enable 'soft' RPC
calls. As you can see from the code, rpc.statd does this. The NLM
client code does so if and only if the NFS mount was soft. The lockd
server does not...
Note: for those RPC calls that don't expect the server to acknowledge
the call and return a value (e.g. NLM_*_MSG, NLM_*_RES) the 'hard'
call unfortunately does not offer any extra guarantees that the server
will *receive* the message. All it guarantees is that the message will
eventually get put on the wire...
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs