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

[Noveck, Dave]

> 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