Hi Tao, On Mon, Jan 4, 2016 at 10:13 AM, Peng Tao <bergwolf@xxxxxxxxxxxxxxx> wrote: > On Tue, Dec 29, 2015 at 2:05 AM, Trond Myklebust > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >> If the client is promising to return the layout ASAP, then there is no >> need to return DELAY and have the server retry. Instead default to the >> normal procedure described in RFC5661. >> >> Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> >> --- >> fs/nfs/callback_proc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c >> index 1b24ad07d4f5..724a9b756ab0 100644 >> --- a/fs/nfs/callback_proc.c >> +++ b/fs/nfs/callback_proc.c >> @@ -214,7 +214,7 @@ static u32 initiate_file_draining(struct nfs_client *clp, >> pnfs_mark_matching_lsegs_return(lo, >> &free_me_list, >> &args->cbl_range); >> - rv = NFS4ERR_DELAY; >> + rv = NFS4_OK; > It is possible that we've cleared all outstanding layout segments of > the file and returns NFS4_OK to CB_LAYOUTRECALL. Then server would be > expecting LAYOUTRETURN while client will not send one. IMO we'd better > re-check list_empty(&lo->plh_segs) to decide what to return here. > Thanks! I'll fix this up in v3... Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
