From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([222.73.24.84]:64917 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1759290Ab1CDJFi (ORCPT ); Fri, 4 Mar 2011 04:05:38 -0500 Message-ID: <4D70AB97.3070502@cn.fujitsu.com> Date: Fri, 04 Mar 2011 17:06:31 +0800 From: Mi Jinlong To: "J. Bruce Fields" CC: NFS Subject: Re: [PATCH 10/17] CLNT: test resues slot ID References: <4D6DE26C.3010103@cn.fujitsu.com> <4D6DE4A5.1050702@cn.fujitsu.com> <20110303061442.GE7724@fieldses.org> <4D6F5B4E.7000903@cn.fujitsu.com> In-Reply-To: <4D6F5B4E.7000903@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 Mi Jinlong : > > J. Bruce Fields: >> On Wed, Mar 02, 2011 at 02:33:09PM +0800, Mi Jinlong wrote: >>> Signed-off-by: Mi Jinlong >>> --- >>> nfs4.1/server41tests/st_sequence.py | 18 ++++++++++++++++++ >>> 1 files changed, 18 insertions(+), 0 deletions(-) >>> >>> diff --git a/nfs4.1/server41tests/st_sequence.py b/nfs4.1/server41tests/st_sequence.py >>> index 4ea5cab..391fc45 100644 >>> --- a/nfs4.1/server41tests/st_sequence.py >>> +++ b/nfs4.1/server41tests/st_sequence.py >>> @@ -363,3 +363,21 @@ def testBadSequenceidAtSlot(t, env): >>> >>> res = c.c.compound([op.sequence(sid, nfs4lib.dec_u32(seqid), 2, 3, True)]) >>> check(res, NFS4ERR_SEQ_MISORDERED) >>> + >>> +def testReuseSlotID(t, env): >>> + """ >>> + >>> + FLAGS: sequence all >>> + CODE: SEQ14 >>> + """ >> Missing description? > > Sorry! I will add it at next version. > >>> + c = env.c1.new_client(env.testname(t)) >>> + # CREATE_SESSION >>> + sess1 = c.create_session() >>> + >>> + sid = sess1.sessionid >>> + res = c.c.compound([op.sequence(sid, 1, 2, 3, True), op.putrootfh()]) >>> + check(res) >>> + >>> + res = c.c.compound([op.sequence(sid, 1, 2, 3, True)]) >>> + # should we also check the ERROR of NFS4ERR_SEQ_FALSE_RETRY ?? >> As I understand it, the server isn't required to recognize false >> retries, so I don't think we can check for that. >> >> The only useful thing to check for, I think, is just to send the same >> request twice and make sure the requests match. >> >> Actually, best would be to do this with a non-idempotent operation. For >> example, send SEQ+RENAME twice and make sure that both renames succeed. >> (Whereas if the server reply cache is broken and the server attempts to >> rename the file again, the second rename will fail with NOENT.) > > Yes, thanks for you advice. > I will send a new patch tomorrow. Maybe the following one is better than before. -- thanks, Mi Jinlong =========================================================