Re: [PATCH RFC] nfsd: serialize layout stateid morphing operations

[Christoph Hellwig <hch@lst.de>]

On Tue, Dec 01, 2015 at 05:48:00PM -0500, Jeff Layton wrote:
> > But for non-forgetful clients I wonder if returning 0 should be
> > interpreted the same as NFS4ERR_DELAY?  Note that we still need to
> > time out the client if it doesn't respond in time, so NFS4ERR_DELAY
> > seems better than 0, but the standard doesn't really talk about
> > return values other than NFS4ERR_NOMATCHING_LAYOUT.
> 
> My interpretation is somewhat different. To me, this is how we'd
> interpret the response from the client (pseudocode):
> 
> NFS_OK:
> 	/* Message received. I'll start returning these layouts soon. */
> NFS4ERR_DELAY:
> 	/* I'm too resource constrained to even process this simple
>            request right now. Please ask me again in a bit. */
> NFS4ERR_NOMATCHING_LAYOUT:
> 	/* Huh? What layout? */
> 
> ...IMO, the spec is pretty clear that a successful response from the
> client just means that it got the message that it should start
> returning layouts. If it happens to return anything before the cb
> response, then that's just luck/coincidence. The server shouldn't count
> on that.

Ok, so for 0 we should re check if the layouts are still outstanding
before sending the next recall.  But given that we have no client
returning that or test cases I'd be tempted to treat OK like DELAY
for now - if the client is properly implemented it will eventually
return NFS4ERR_NOMATCHING_LAYOUT.  We can add a big comment on why
we're doing that so that it's obvious.