[pnfs] [nfsv4] Re: what error should be returned to an impatient client?

[Talpey, Thomas]

I'm fine with sending the error, then closing the connection.
The client has been proven insane, so there is no reason to
attempt recovery since it almost certainly won't help.

We should not introduce a new error return for this however,
especially not BUSYSLOT which would be a contradiction in
terms. SEQ_MISORDERED is more than enough to indicate the
error. Is carving a protocol distinction between one kind of
garbage and another kind at all worth it? Not to me.

Tom.


At 10:46 AM 4/11/2007, Noveck, Dave wrote:
>> There is no replay protection, and the client will have
>> to use XID matching to detect the server's reply.
>
>This is a very interesting point.  I think it relates to
>the discussion at the review meeting abut what the spec
>should say about the XID.  Requiring the server at least
>to propagate it on the reply so that if the client screws
>up, he can at least see the error he gets, seems reasonable
>to me.
>
>Although a server may close the connection, I would hope that
>as we try to debug prototypes of this stuff, we try to give
>as meaningful a response to the client as possible, even 
>when he send garbage.  Any help on the type of garbage can
>save a lot debugging time, and that's a good thing.
>
>I think the concept that we are closed to .x changes should 
>not apply to the addition of errors.  We know the per-op 
>error lists are not complete in the spec anyway, so clients
>will not be depending on specific limits as to errors.
>
>I like the idea of a separate error to tell the client he
>sent unbelievably stinky rotten garbage, which this would
>be.
>
>-----Original Message-----
>From: Talpey, Thomas 
>Sent: Wednesday, April 11, 2007 10:27 AM
>To: Benny Halevy
>Cc: pnfs at linux-nfs.org; nfsv4 at ietf.org
>Subject: [nfsv4] Re: [pnfs] what error should be returned to an
>impatient client?
>
>
>Well, since the client violated the no-retransmit principle, the
>server could simply close the connection. In fact on an RDMA
>transport, this may happen from the hardware itself. In my opinion
>this is what the server should do. But, if the server is going to
>return an error, it should be NFS4ERR_SEQ_MISORDERED.
>
>Remember, in this kind of situation, the slot and sequence are
>completely invalid, and the exchange is basically outside the
>session. There is no replay protection, and the client will have
>to use XID matching to detect the server's reply. Basically,
>it's an invalid protocol request, almost as if the client had sent
>RPC garbage.
>
>Tom.
>
>At 10:19 AM 4/11/2007, Benny Halevy wrote:
>>while reviewing the sessions text in draft-10 I realized that
>>it is not clear what error the server should return if the
>>client sent a new request on a slot that's still in use.
>>
>>In the currently linux implementation (in Andy's latest patches)
>>nfsd4_sequence() just allows that
>>	status = nfs_ok;
>>	if (nfs41_get_slot_state(slot) != NFS4_SLOT_AVAILABLE)
>>		goto out;
>>...
>>out:
>>	dprintk("%s returns %d\n", __FUNCTION__, status);
>>	nfs4_unlock_state();
>>	return status;
>>
>>I suggest returning NFS4ERR_BADSLOT or add a new error code
>NFS4ERR_BUSYSLOT
>>(other alternatives could be NFS4ERR_INVALID or
>NFS4ERR_SEQ_MISORDERED).
>>
>>Benny
>>_______________________________________________
>>pNFS mailing list
>>pNFS at linux-nfs.org
>>http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>
>
>_______________________________________________
>nfsv4 mailing list
>nfsv4 at ietf.org
>https://www1.ietf.org/mailman/listinfo/nfsv4