All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bian Naimeng <biannm@cn.fujitsu.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] Revert "nfsd4: distinguish expired from stale stateids"
Date: Mon, 08 Nov 2010 16:52:36 +0800	[thread overview]
Message-ID: <4CD7BA54.2050403@cn.fujitsu.com> (raw)
In-Reply-To: <20101002224954.GD18079@fieldses.org>



J. Bruce Fields wrote:
> On Wed, Sep 22, 2010 at 03:39:33PM -0400, J. Bruce Fields wrote:
>> On Tue, Aug 03, 2010 at 05:12:06PM +0800, Bian Naimeng wrote:
>>>   As i see, this question is difficult to slove. Freebsd looks like nerver return 
>>>   the NFSERR_EXPIRED error.  And solaris more than happy to return NFSERR_EXPIRED 
>>>   rather than NFSERR_BAD_STATEID when the stateid is not found at server.
>>>
>>>   I mean it's difficult to distinguish expired_stateid and bad_stateid(they are not
>>>   exist at server), so maybe we have not a exactly solution to solve it.
>>>
>>>   Maybe we should choose which error we are more needed, NFSERR_EXPIRED  or NFSERR_BAD_STATEID?
>> Yes, that would probably be simplest.
> 
> So, like this?

  Hi bruce,

     I'm sorry to reply it so later, it looks good to me. ^_^

  Best Regards
    Bian

> 
> --b.
> 
> commit 3d5bdf44f73f2e4136d27fe7bd45b9ca6674e590
> Author: J. Bruce Fields <bfields@redhat.com>
> Date:   Sat Oct 2 18:42:39 2010 -0400
> 
>     nfsd4: return expired on unfound stateid's
>     
>     Commit 78155ed75f470710f2aecb3e75e3d97107ba8374 "nfsd4: distinguish
>     expired from stale stateids" attempted to distinguish expired and stale
>     stateid's using time information that may not have been completely
>     reliable, so I reverted it.
>     
>     That was throwing out the baby with the bathwater; we still do want to
>     return expired, but let's do that using the simpler approach of just
>     assuming any stateid is expired if it looks like it was given out by the
>     current server instance, but we can't find it any more.
>     
>     This may help clients that are recovering from network partitions.
>     
>     Reported-by: Bian Naimeng <biannm@cn.fujitsu.com>
>     Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 596702e..02c23b7 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -3046,7 +3046,11 @@ nfs4_preprocess_stateid_op(struct nfsd4_compound_state *cstate,
>  	if (STALE_STATEID(stateid)) 
>  		goto out;
>  
> -	status = nfserr_bad_stateid;
> +	/*
> +	 * We assume that any stateid that has the current boot time,
> +	 * but that we can't find, is expired:
> +	 */
> +	status = nfserr_expired;
>  	if (is_delegation_stateid(stateid)) {
>  		dp = find_delegation_stateid(ino, stateid);
>  		if (!dp)
> @@ -3066,6 +3070,7 @@ nfs4_preprocess_stateid_op(struct nfsd4_compound_state *cstate,
>  		stp = find_stateid(stateid, flags);
>  		if (!stp)
>  			goto out;
> +		status = nfserr_bad_stateid;
>  		if (nfs4_check_fh(current_fh, stp))
>  			goto out;
>  		if (!stp->st_stateowner->so_confirmed)
> @@ -3140,8 +3145,9 @@ nfs4_preprocess_seqid_op(struct nfsd4_compound_state *cstate, u32 seqid,
>  		 * a replayed close:
>  		 */
>  		sop = search_close_lru(stateid->si_stateownerid, flags);
> +		/* It's not stale; let's assume it's expired: */
>  		if (sop == NULL)
> -			return nfserr_bad_stateid;
> +			return nfserr_expired;
>  		*sopp = sop;
>  		goto check_replay;
>  	}
> @@ -3406,6 +3412,7 @@ nfsd4_delegreturn(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
>  	status = nfserr_bad_stateid;
>  	if (!is_delegation_stateid(stateid))
>  		goto out;
> +	status = nfserr_expired;
>  	dp = find_delegation_stateid(inode, stateid);
>  	if (!dp)
>  		goto out;
> 
> 
> 

-- 
Regards
Bian Naimeng


  reply	other threads:[~2010-11-08  9:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 23:37 [PATCH] Revert "nfsd4: distinguish expired from stale stateids" J. Bruce Fields
2010-08-02  3:35 ` Bian Naimeng
2010-08-02 13:50   ` J. Bruce Fields
2010-08-03  9:12     ` Bian Naimeng
2010-09-22 19:39       ` J. Bruce Fields
2010-10-02 22:49         ` J. Bruce Fields
2010-11-08  8:52           ` Bian Naimeng [this message]
2010-11-08 16:08             ` J. Bruce Fields
2010-08-23  7:39     ` Bian Naimeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD7BA54.2050403@cn.fujitsu.com \
    --to=biannm@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.