From: "J. Bruce Fields" <bfields@fieldses.org>
To: Mi Jinlong <mijinlong@cn.fujitsu.com>
Cc: "Trond.Myklebust" <trond.myklebust@fys.uio.no>,
NFSv3 list <linux-nfs@vger.kernel.org>,
mingo@elte.hu
Subject: Re: [RFC] NLM server can not process retransmited request correctly
Date: Mon, 2 Nov 2009 15:09:56 -0500 [thread overview]
Message-ID: <20091102200956.GC19271@fieldses.org> (raw)
In-Reply-To: <4AEEA622.6000705@cn.fujitsu.com>
On Mon, Nov 02, 2009 at 05:28:02PM +0800, Mi Jinlong wrote:
> Hi Trond et al:
>
> When i test the nfslock of NFSv3 at RHEL5.3GA (kernel: 2.6.18-128.el5),
> NLM server can not process client's retransmited request correctly.
>
> Steps of my test likes followed:
> client server
> | |
> step1 | open file |
> open |------------------------------->|
> | ok |
> |<-------------------------------|
> | | step2
> | -> | <- service nfslock stop
> | |
> step3 | WL1: write lock request{0, 0} |
> fcntl |------------------------------->|
> | |
> | WL1_re: WL1 retransmit |
> |------------------------------->|
> | |
> | WL1.reply ENOLCK |
> |<-------------------------------|
> | | step4
> | -> | <- service nfslock start
> | |
> step5 | WL2: write lock request{0, 0} |
> fcntl |------------------------------->|
> | |
> | WL1_re.reply OK |
> |<-------------------------------|
> | WL2.reply EBLOCKD |
> |<-------------------------------|
> V V
>
> Client can not acquire for write lock any more after step4.
>
> Reason:
> Server reply ENOLCK for WL1 to client because nfslock service stoped,
I don't completely understand that part: is it because the monitor call
to statd fails?
> but it can not distinguish retransmited request with normal request,
> so it reply OK for WL1_re to client after nfslock service start. But
> fcntl client called will return when it receive WL1.reply, WL1_re.reply
> will be droped at Client. So that, the lock between client and server
> is different. When client send a some lock request to server again,
> it will get a EBLOCKD error from Server.
But, OK, I get the idea, and generic DRC code shared by nfsd and nlm
makes sense to me; thanks for looking into this.
--b.
next prev parent reply other threads:[~2009-11-02 20:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 9:28 [RFC] NLM server can not process retransmited request correctly Mi Jinlong
2009-11-02 9:35 ` [PATCH 1/3] Add a common DRC for sunrpc Mi Jinlong
2009-11-02 9:39 ` [PATCH 2/3] Add DRC for NLM using sunrpc's common DRC Mi Jinlong
2009-11-02 9:45 ` [PATCH 3/3] Modify nfs's DRC to use " Mi Jinlong
2009-11-02 20:09 ` J. Bruce Fields [this message]
2009-11-03 9:37 ` [RFC] NLM server can not process retransmited request correctly Mi Jinlong
2009-11-06 23:07 ` J. Bruce Fields
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=20091102200956.GC19271@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mijinlong@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=trond.myklebust@fys.uio.no \
/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.