I'm observing a consistent failure of LAYOUTCOMMIT when the NFS client accesses a pNFS share using filelayout. Below is the sequence of events: 1, The client opens a file for writing and successfully receives a layout (stateid with seqid = 1). 2, The client writes data to the data server (DS) successfully. 3, The NFS server sends a CB_LAYOUTRECALL (stateid with seqid = 2) due to some change on the server side. 4, The client sends a LAYOUTCOMMIT (still with seqid = 1), followed by a LAYOUTRETURN (with seqid = 2). 5, The server responds to LAYOUTCOMMIT with NFS4ERR_OLD_STATEID. 6, The server responds to LAYOUTRETURN with NFS4ERR_OK. 7, The client retries LAYOUTCOMMIT (still using seqid = 1). 8, The server replies with NFS4ERR_BAD_STATEID because the state was already removed when processing the LAYOUTRETURN. It seems there may be two issues with the Linux NFS client’s behavior: 1, The client should not send LAYOUTRETURN before receiving a non-retryable response to LAYOUTCOMMIT. 2, After receiving a CB_LAYOUTRECALL, the client should not continue using the old seqid. Would you consider this a bug in the client? Or is there something I may have misunderstood in the protocol behavior? Thanks, Haihua Yang
