On Fri, Mar 03 2017, Jeff Layton wrote:
>
> There is one special case...
>
> When the server does a CB_LAYOUTRECALL, the client can reply with
> NFS4ERR_NOMATCHING_LAYOUT if it's not actively using the layout at the
> time. With that, the client isn't expected to do a LAYOUTRETURN.
>
> Any other status on the CB_LAYOUTRECALL however does require a
> LAYOUTRETURN.
Thanks, both to you and Christoph, for this pointer.
Things are starting to make sense.
However RFC5661 says under
Operation 5: CB_LAYOUTRECALL - Recall Layout from Client
While the client responds to the CB_LAYOUTRECALL immediately, the
operation is not considered complete (i.e., considered pending) until
all affected layouts are returned to the server via the LAYOUTRETURN
operation.
which seems to strongly imply that a LAYOUTRETURN is expected. No
alternative is listed.
Further:
The NFS4ERR_NOMATCHING_LAYOUT error is only returned when the client
does not hold layouts for the file or if the client does not have
any overlapping layouts for the specification in the layout recall.
This is an *error* condition. The client really does still hold
the layouts if it hasn't sent "LAYOUTRETURN". The fact that the linux
client chooses to forget them and won't ever use them again isn't really
the same thing as "not hold[ing] layouts".
If I were a server author and I got NFS4ERR_NOMATCHING_LAYOUT for a
CB_LAYOUTRECALL where a I knew for certain that the client really did
have the layout, then I would probably feel justified in discarding all
state held by that confused client, and requiring to re-establish
everything (because I cannot trust anything any more).
So the Netapp filer is clearly doing the wrong thing, as we doesn't send
CB_LAYOUTRECALL. But I'm far from convinced that Linux is doing the
right thing by replying NFS4ERR_NOMATCHING_LAYOUT.
However, I'm not going to try to "fix" anything here. Hopefully we can
manage to stumble forward.
Thanks again,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
