[nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR
Jwu-Shyan Tarng <jstarng@us.ibm.com> Sun, 04 July 2010 02:52 UTC
Return-Path: <jstarng@us.ibm.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263E23A6960 for <nfsv4@core3.amsl.com>; Sat, 3 Jul 2010 19:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWb7cRn-BcNF for <nfsv4@core3.amsl.com>; Sat, 3 Jul 2010 19:51:59 -0700 (PDT)
Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 45D233A68BD for <nfsv4@ietf.org>; Sat, 3 Jul 2010 19:51:59 -0700 (PDT)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o642mMn9001777 for <nfsv4@ietf.org>; Sat, 3 Jul 2010 20:48:22 -0600
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o642pof7143844 for <nfsv4@ietf.org>; Sat, 3 Jul 2010 20:51:50 -0600
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o642pnGw027093 for <nfsv4@ietf.org>; Sat, 3 Jul 2010 20:51:50 -0600
Received: from d03nm132.boulder.ibm.com (d03nm132.boulder.ibm.com [9.17.195.172]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o642pnRE027090 for <nfsv4@ietf.org>; Sat, 3 Jul 2010 20:51:49 -0600
In-Reply-To: <1278194481.2808.9.camel@heimdal.trondhjem.org>
References: <F7E65964-7ED7-4152-B6B9-BC5A8C037CEF@gmail.com> <1278194481.2808.9.camel@heimdal.trondhjem.org>
To: nfsv4 nfsv4 <nfsv4@ietf.org>
MIME-Version: 1.0
X-KeepSent: B684E0DF:FD64C02B-87257756:000E66A1; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OFB684E0DF.FD64C02B-ON87257756.000E66A1-88257756.000FBB17@us.ibm.com>
From: Jwu-Shyan Tarng <jstarng@us.ibm.com>
Date: Sat, 03 Jul 2010 19:51:47 -0700
X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 8.0.1|February 07, 2008) at 07/03/2010 20:51:49, Serialize complete at 07/03/2010 20:51:49
Content-Type: multipart/alternative; boundary="=_alternative 000FBB1488257756_="
Subject: [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jul 2010 02:52:00 -0000
Can someone help to answer the following questions? - Can the previous V4 OPEN with CLAIM=CLAIM_DELEGATE_CUR impact on the later V4 OPEN delegation grant with different SHARE access since CLAIM_DELEGATE_CUR is done as part of recalling a delegation based on RFC? - There is a test sequence in the following: 1 OPEN for Read which gets READ delegation with delegation stateid, dstateid, andopen stateid, ostateid 2 Read with dstateid. - Expect NFS4_OK 3 CLOSE with ostateid - Expect NFS4_OK 4 OPEN with CLAIM=CLAIM_DELEGATE_CUR with dstateid and get open stateid, ostateid2, back. Read with dstateid. - Expect NFS4_OK Read with ostateid2. - Expect NFS4_OK 5 OPEN for write for this file (like OPEN upgrade) Questions: 1) Is the old dstateid still valid now? If it is still valid, is this dstateid representing READ delegation or WRITE delegation? 2) Can this open for write get write delegation stateid besides open stateid returned to the client? If there is no delegation stateid returned to the client, is there any delegation existing on the client side? Regards, Jwu-Shyan Tarng NFS Development
- [nfsv4] IETF 78 NFSv4 session currently schedule … Spencer
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Trond Myklebust
- [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGAT… Jwu-Shyan Tarng
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Sorin Faibish
- Re: [nfsv4] NFS V4 OPEN delegation with CLAIM_DEL… Rick Macklem
- Re: [nfsv4] NFS V4 OPEN delegation with CLAIM_DEL… Trond Myklebust
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Tom Haynes
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Sorin Faibish
- Re: [nfsv4] NFS V4 OPEN delegation with CLAIM_DEL… Noveck_David
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Dean Hildebrand
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Noveck_David
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Tom Haynes
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Tom Haynes
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Dean Hildebrand
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Everhart, Craig
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… David P. Quigley
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… sfaibish
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Tom Haynes
- Re: [nfsv4] IETF 78 NFSv4 session currently sched… Tom Haynes