[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