[nfsv4] can a server replace a read deleg with a write deleg?

Rick Macklem <rmacklem@uoguelph.ca> Sun, 04 July 2010 16:10 UTC

Return-Path: <rmacklem@uoguelph.ca>
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 C44EC3A67F2 for <nfsv4@core3.amsl.com>; Sun, 4 Jul 2010 09:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 9icSyH-NCgYk for <nfsv4@core3.amsl.com>; Sun, 4 Jul 2010 09:10:54 -0700 (PDT)
Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by core3.amsl.com (Postfix) with ESMTP id B7BB63A67B7 for <nfsv4@ietf.org>; Sun, 4 Jul 2010 09:10:54 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUFAHxPMEyDaFvJ/2dsb2JhbACTMQEBjDVxuyuFJQQ
X-IronPort-AV: E=Sophos;i="4.53,536,1272859200"; d="scan'208";a="82873542"
Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Jul 2010 12:10:52 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 29EEBFB808E for <nfsv4@ietf.org>; Sun, 4 Jul 2010 12:10:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca
Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcJP+sRm85uB for <nfsv4@ietf.org>; Sun, 4 Jul 2010 12:10:53 -0400 (EDT)
Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 64963FB8064 for <nfsv4@ietf.org>; Sun, 4 Jul 2010 12:10:53 -0400 (EDT)
Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o64GS2J07571 for <nfsv4@ietf.org>; Sun, 4 Jul 2010 12:28:02 -0400 (EDT)
X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs
Date: Sun, 04 Jul 2010 12:28:01 -0400
From: Rick Macklem <rmacklem@uoguelph.ca>
X-X-Sender: rmacklem@muncher.cs.uoguelph.ca
To: nfsv4@ietf.org
Message-ID: <Pine.GSO.4.63.1007041217520.6453@muncher.cs.uoguelph.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [nfsv4] can a server replace a read deleg with a write deleg?
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 16:10:55 -0000

Somewhat tangencial to the recent thread, what about the following
simple case:
- client opens foo for reading and gets read_deleg_stateid_foo
- client opens foo for writing against the server (which it must do
   when it holds a read delegation)

Now, if the server sees that this client is the only one with a read
delegation for (and opens on) "foo", it could issue a write delegation
to the client for "foo".
- To do this does it first need to CBRecall the read delegation? (If so,
   it probably cannot issue the write delegation for this open, since it
   would take too long to reply to the Open unless it returns NFS4ERR_DELAY
   for the Open for a while. Not an ideal situation.)
OR
- Can it return a write delegation for "foo" in the write open reply?
   - If it is allowed to do this, does this delegation replace
     read_delegation_stateid_foo or is there now multiple delegations for
     "foo" issued to the same client?
     (I don't like the concept of having multiple delegations issued to
      the same client for the same file concurrently and I'm pretty sure
      my client isn't implemented to handle this case. Without looking at
      the code to be sure, I think it logs an error and throws away the
      new second delegation.)

I don't think this is clarified in RFC3530, but please correct me if I'm
incorrect w.r.t. this.

rick