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: Tue, 03 Aug 2010 17:12:06 +0800 [thread overview]
Message-ID: <4C57DD66.1070001@cn.fujitsu.com> (raw)
In-Reply-To: <20100802135036.GA12637@fieldses.org>
> On Mon, Aug 02, 2010 at 11:35:01AM +0800, Bian Naimeng wrote:
>>> From: J. Bruce Fields <bfields@citi.umich.edu>
>>>
>>> This reverts commit 78155ed75f470710f2aecb3e75e3d97107ba8374.
... snip ...
>>>
>> Hi bruce, if remove this patch, some my test will fail. So what's your opinion
>> for those test case.
>>
>> STEP1: open the file, and get a open stateid (STATEID).
>> STEP2: shutdown the network between client and server
>> STEP3: keep the network partition lease_time(90s by default) seconds
>> STEP4: recovery network
>> STEP5: do some IO operation, such as LOCK.
>>
>> If i use the patch 78155ed75f470710f2aecb3e75e3d97107ba8374, this case will OK
>> at STEP5, however, it's will fail when remove this patch.
>
> How does it fail, exactly?
>
My client is linux-2.6.32, server is linux-2.6.35.
At step5, client will use the old open stateid to send lock request, and server
return NFS4ERR_BAD_STATEID because this stateid have be released,
then client's kernel return EIO to userspace.
If i apply this patch, server will return NFS4ERR_EXPIRED at step5, then client
will start recovery procedure.
>> So i think it's no good for the network recovery, what do you think about it,
>> or give me some suggestions, thanks very much.
>
> The theoretical problem with the patch is that time changes could cause
> the server to return spurious errors when the client hands it state that
> should still be good.
>
En... Would you give me a example?
> We might be able to solve that by using a different time source?
>
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?
--
Regards
Bian Naimeng
next prev parent reply other threads:[~2010-08-03 9:13 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 [this message]
2010-09-22 19:39 ` J. Bruce Fields
2010-10-02 22:49 ` J. Bruce Fields
2010-11-08 8:52 ` Bian Naimeng
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=4C57DD66.1070001@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.