Re: [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR

<Noveck_David@emc.com> Tue, 06 July 2010 15:49 UTC

Return-Path: <Noveck_David@emc.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 8B7A23A6934 for <nfsv4@core3.amsl.com>; Tue, 6 Jul 2010 08:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6FXE-qv0Hm65 for <nfsv4@core3.amsl.com>; Tue, 6 Jul 2010 08:49:43 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4086A3A65A6 for <nfsv4@ietf.org>; Tue, 6 Jul 2010 08:49:43 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o66FnijH009497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 11:49:44 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 6 Jul 2010 11:49:35 -0400
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o66Fk5fq008371; Tue, 6 Jul 2010 11:48:09 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.45]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 11:48:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1D22.9E4200DC"
Date: Tue, 06 Jul 2010 11:48:02 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D8001A4A250@CORPUSMX50A.corp.emc.com>
In-Reply-To: <OFB684E0DF.FD64C02B-ON87257756.000E66A1-88257756.000FBB17@us.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR
Thread-Index: AcsbI+XTYaOvIwx1To+ryv3+oqr/qgB/YRXA
References: <F7E65964-7ED7-4152-B6B9-BC5A8C037CEF@gmail.com><1278194481.2808.9.camel@heimdal.trondhjem.org> <OFB684E0DF.FD64C02B-ON87257756.000E66A1-88257756.000FBB17@us.ibm.com>
From: Noveck_David@emc.com
To: jstarng@us.ibm.com, nfsv4@ietf.org
X-OriginalArrivalTime: 06 Jul 2010 15:48:04.0833 (UTC) FILETIME=[9F442D10:01CB1D22]
X-EMM-EM: Active
Subject: Re: [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: Tue, 06 Jul 2010 15:49:44 -0000

There is no provisions for delegation upgrade.  I don't think it says
that anywhere but I would assume that the fact that this is not
described allows you to assume that it does not exist.
 
So, in your example, when you do the open for write, the delegation will
be recalled.  If you know that is going to happen, the client is
well-advised to return the read delegation in the COMPOUND, before doing
the open upgrade. 

________________________________

From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
Of Jwu-Shyan Tarng
Sent: Saturday, July 03, 2010 10:52 PM
To: nfsv4 nfsv4
Subject: [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR



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