Hi Neil, On Mon, 2017-03-06 at 14:54 +1100, NeilBrown wrote: > 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. > Please see RFC5661, Section 12.5.5.1 https://tools.ietf.org/html/rfc566 1#section-12.5.5.1 That section has a full documentation of what the server should interpret NFS4ERR_NOMATCHING_LAYOUT to mean, and should explain why the Linux client behaviour is quite correct w.r.t. the spec. There are a couple of errata to consider too, but they mainly try to nail down the expected behaviour for a couple of corner cases. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
