aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTrond Myklebust <trond.myklebust@hammerspace.com>2018-06-23 13:35:28 -0400
committerTrond Myklebust <trond.myklebust@hammerspace.com>2018-07-26 16:25:24 -0400
commit00bcbe119f915dec256f211f9dbfc93cb64773bc (patch)
treefe62cb22048f7c616504b10b32c7c964f4f2f15e
parentpNFS: Don't discard layout segments that are marked for return (diff)
downloadlinux-dev-00bcbe119f915dec256f211f9dbfc93cb64773bc.tar.xz
linux-dev-00bcbe119f915dec256f211f9dbfc93cb64773bc.zip
pNFS: Don't update the stateid when replying NFS4ERR_DELAY to a layout recall
RFC5661 doesn't state directly that the client should update the layout stateid if it returns NFS4ERR_NOMATCHING_LAYOUT in response to a recall, however it does state that this error will "cleanly indicate completion" on par with returning the layout. For this reason, we assume that the client should update the layout stateid. The Linux pNFS server definitely does expect this behaviour. However, if the client replies NFS4ERR_DELAY, then it is stating that the recall was not processed, so it would be very wrong to update the layout stateid. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
-rw-r--r--fs/nfs/callback_proc.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
index af2322256aa4..efca3d6c89f2 100644
--- a/fs/nfs/callback_proc.c
+++ b/fs/nfs/callback_proc.c
@@ -273,7 +273,6 @@ static u32 initiate_file_draining(struct nfs_client *clp,
rv = pnfs_check_callback_stateid(lo, &args->cbl_stateid);
if (rv != NFS_OK)
goto unlock;
- pnfs_set_layout_stateid(lo, &args->cbl_stateid, true);
/*
* Enforce RFC5661 Section 12.5.5.2.1.5 (Bulk Recall and Return)
@@ -283,6 +282,7 @@ static u32 initiate_file_draining(struct nfs_client *clp,
goto unlock;
}
+ pnfs_set_layout_stateid(lo, &args->cbl_stateid, true);
switch (pnfs_mark_matching_lsegs_return(lo, &free_me_list,
&args->cbl_range,
be32_to_cpu(args->cbl_stateid.seqid))) {