Subject: [nfsv4] [PATCH] Don't recall a READ delegation if the only holder opens the file for write

From: Trond Myklebust <[email-masked]>
Date: Thu, 1 Sep 2011 15:43:57 -0400

This requires a slight change to the definition of READ delegations. Instead
of defining a READ delegation as something that guarantees the file will
never change, we define it to mean that the file will not be changed
by another client.
---
 nfsv4_middle_client_cache.xml |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/nfsv4_middle_client_cache.xml b/nfsv4_middle_client_cache.xml
index fcbefa8..f5fbe9b 100644
--- a/nfsv4_middle_client_cache.xml
+++ b/nfsv4_middle_client_cache.xml
@@ -658,7 +658,9 @@
       There are two types of open delegations, OPEN_DELEGATE_READ and
       OPEN_DELEGATE_WRITE.  A OPEN_DELEGATE_READ delegation allows a
       client to handle, on its own, requests to
-      open a file for reading that do not deny read access to others.
+      open a file for reading that do not deny read access to others. It MUST,
+      however, continue to send all requests to open a file for writing to the
+      server.
       Multiple OPEN_DELEGATE_READ delegations may be outstanding simultaneously
       and do not conflict.  A OPEN_DELEGATE_WRITE delegation allows the client to
       handle, on its own, all opens.  Only one OPEN_DELEGATE_WRITE delegation may
@@ -667,9 +669,11 @@
     </t>
 
     <t>
-      When a client has a OPEN_DELEGATE_READ delegation, it may not make any changes
-      to the contents or attributes of the file but it is assured that no
-      other client may do so.  When a client has a OPEN_DELEGATE_WRITE delegation,
+      When a single client holds a OPEN_DELEGATE_READ delegation, it is assured that
+      no other client may modify the contents or attributes of the file. If more than
+      one client holds an OPEN_DELEGATE_READ delegation, then the contents and
+      attributes of that file are not allowed to change.
+      When a client has a OPEN_DELEGATE_WRITE delegation,
       it may modify the file data since no other client will be accessing
       the file's data.  The client holding a OPEN_DELEGATE_WRITE delegation may only
       affect file attributes which are intimately connected with the file
@@ -780,9 +784,11 @@
         OPEN delegation allows much of the message overhead associated with
         the opening and closing files to be eliminated.  An open when an open
         delegation is in effect does not require that a validation message be
-        sent to the server.  The continued endurance of the "OPEN_DELEGATE_READ
+        sent to the server unless there exists a potential for conflict with the
+        requested share mode. The continued endurance of the "OPEN_DELEGATE_READ
         delegation" provides a guarantee that no OPEN for write and thus no
-        write has occurred.  Similarly, when closing a file opened for write
+        write has occurred that did not originate from this client.
+        Similarly, when closing a file opened for write
         and if OPEN_DELEGATE_WRITE delegation is in effect, the data written does
         not have to be flushed to the server until the open delegation is
         recalled.  The continued endurance of the open delegation provides
-- 
1.7.6

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 1 Sep 2011 16:26:24 -0400

> +++ b/nfsv4_middle_client_cache.xml

s/a OPEN/an OPEN/.

Looks reasonable to me otherwise.

--b.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 01 Sep 2011 16:58:44 -0400

> > +      When a client has a OPEN_DELEGATE_WRITE delegation,

Sure. I can fix that too while I'm at it...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 1 Sep 2011 21:47:51 +0000

I appreciate the attempt to provide for delegation upgrade (read -> write).

As we know, we have solved this in 4.1 and have lived with the current
state of affairs in 4.0.

If there is consensus that this upgrade is needed, then we need more
text to ensure that the issues/behaviors have been appropriately captured.

For example, is the server required to provide for upgrade or can it
continue to recall the read delegation before responding to the OPEN
request?  If it does support read/write delegation upgrade, is the same
delegation stated used?  Is the return of a differing delegation type/stated
an indication that the server supports the client holding both a read and
write delegation?  If it does support such a thing, is the client then
required to return both of the delegation stateids (read and write)?

I don't have an opinion about any of the above but it would be prudent
to have text that provides expected behavior and intent and allows for
the current server behaviors of recalling the delegation prior
to processing an OPEN for write.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Trond Myklebust
> Sent: Thursday, September 01, 2011 12:44 PM
> To: [email-masked]; [email-masked]
> Cc: Trond Myklebust
> Subject: [nfsv4] [PATCH] Don't recall a READ delegation if the only holder
> opens the file for write
> 
> This requires a slight change to the definition of READ delegations.
> Instead of defining a READ delegation as something that guarantees the
> file will never change, we define it to mean that the file will not be
> changed by another client.
> ---
>        handle, on its own, all opens.  Only one OPEN_DELEGATE_WRITE
> delegation may @@ -667,9 +669,11 @@
>      </t>
> 
>      <t>
> +        requested share mode. The continued endurance of the
> + "OPEN_DELEGATE_READ

---

From: <[email-masked]>
Date: Thu, 1 Sep 2011 18:26:45 -0400

While it is true that this issue was raised in connection with a discussion
of Rick's question about delegation upgrade, we should not confuse the two.

Although Rick can speak for himself, I believe that part of the motivation
For the upgrade logic was the existing "gratuitous 'may not'".  Now that
that is gone, there is no motivation and no occasion, for the upgrade
logic that was discussed.

If it is no longer the case that an open for write would cause the recall
and/or revocation of an existing read delegation by the same client, then
There is no way that a write delegation can be granted.

It is still true that someone can, if he wants, return the read delegation and ask
for a write delegation, but I don't think the 4.0 spec should take any special notice 
of that.  As Spencer noted, delegation upgrade is addressed in v4.1.  

I agree with the proposed change and will argue that there is no need for any
delegation-upgrade-related text in the bis, once the change is adopted.

> allows for

I think the fact that a server may recall a delegation at any time, covers things 
adequately.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, September 01, 2011 5:48 PM
To: Trond Myklebust; [email-masked]; [email-masked]
Subject: Re: [nfsv4] [PATCH] Don't recall a READ delegation if the only holder opens the file for write

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 2 Sep 2011 00:06:50 +0000

<see below>

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 3:27 PM
> To: Spencer Shepler; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [nfsv4] [PATCH] Don't recall a READ delegation if the only
> holder opens the file for write
> 
> While it is true that this issue was raised in connection with a
> discussion of Rick's question about delegation upgrade, we should not
> confuse the two.
> 
> It is still true that someone can, if he wants, return the read delegation
> and ask for a write delegation, but I don't think the 4.0 spec should take
> any special notice of that.  As Spencer noted, delegation upgrade is
> addressed in v4.1.

Ah, okay.  So the point is if the client does not DELEGRETURN the read delegation
and then opens the file for write, the server does not have to recall/revoke
the read delegation as long as the server does not provide a write delegation.
The client can simultaneously hold the file open for write and have a read delegation.

If the server would like to provide a write delegation to the client and
that same client holds a read delegation, the server would first recall
or revoke the read delegation and then provide the write delegation.

Interesting subtlety.

Spencer

> 
> I agree with the proposed change and will argue that there is no need for
> any delegation-upgrade-related text in the bis, once the change is
> adopted.
> 
> > allows for
> > the current server behaviors of recalling the delegation prior to
> > processing an OPEN for write.
> 
> I think the fact that a server may recall a delegation at any time, covers
> things adequately.
> 
> Spencer Shepler
> If there is consensus that this upgrade is needed, then we need more text
> to ensure that the issues/behaviors have been appropriately captured.
> 
> delegation stated used?  Is the return of a differing delegation
> type/stated an indication that the server supports the client holding both
> a read and write delegation?  If it does support such a thing, is the
> client then required to return both of the delegation stateids (read and
> write)?
> 
> I don't have an opinion about any of the above but it would be prudent to
> have text that provides expected behavior and intent and allows for the
> current server behaviors of recalling the delegation prior to processing
> an OPEN for write.
> 
> Spencer
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Trond Myklebust
> > Subject: [nfsv4] [PATCH] Don't recall a READ delegation if the only
> > holder opens the file for write
> >
> > diff --git a/nfsv4_middle_client_cache.xml
> > b/nfsv4_middle_client_cache.xml index fcbefa8..f5fbe9b 100644
> > +      open a file for reading that do not deny read access to others.
> > + It
> > MUST,
> > +      however, continue to send all requests to open a file for
> > + writing
> > to the
> > +      server.
> > -      When a client has a OPEN_DELEGATE_READ delegation, it may not
> make
> > any changes
> > +      When a single client holds a OPEN_DELEGATE_READ delegation, it
> > + is
> > assured that
> > +      no other client may modify the contents or attributes of the
> file.
> > If more than
> >        affect file attributes which are intimately connected with the
> > file @@ -780,9 +784,11 @@
> > +        sent to the server unless there exists a potential for
> > + conflict
> > with the

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 01 Sep 2011 21:09:58 -0400

> or revoke the read delegation and then provide the write delegation.

Exactly. The objective is to loosen the server rules sufficiently to
enable the client to hold on to its read delegation in situations where
it just wants to make a small change to the file, and where that would
not affect the caching behaviour of other clients.

Existing servers are, of course, not required to implement this new
model, and remain compliant provided that they complied with the
requirements in the original RFC3530.

Cheers
  Trond

NetApp

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 2 Sep 2011 01:14:11 +0000

> From: Trond Myklebust [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 6:10 PM
> To: Spencer Shepler
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: RE: [nfsv4] [PATCH] Don't recall a READ delegation if the
> > > only holder opens the file for write
> > >
> > > discussion of Rick's question about delegation upgrade, we should
> > > not confuse the two.
> > >
> > > Although Rick can speak for himself, I believe that part of the
> > > motivation For the upgrade logic was the existing "gratuitous 'may
> > > not'".  Now that that is gone, there is no motivation and no
> > > occasion, for the upgrade logic that was discussed.
> > >
> > > If it is no longer the case that an open for write would cause the
> > > recall and/or revocation of an existing read delegation by the same
> > > client, then There is no way that a write delegation can be granted.
> > >
> > > It is still true that someone can, if he wants, return the read
> > > delegation and ask for a write delegation, but I don't think the 4.0
> > > spec should take any special notice of that.  As Spencer noted,
> > > delegation upgrade is addressed in v4.1.
> >
> > Ah, okay.  So the point is if the client does not DELEGRETURN the read
> > delegation and then opens the file for write, the server does not have
> > to recall/revoke the read delegation as long as the server does not
> provide a write delegation.
> > If the server would like to provide a write delegation to the client
> > and that same client holds a read delegation, the server would first
> > recall or revoke the read delegation and then provide the write
> delegation.
> >
> > Interesting subtlety.
> 
> enable the client to hold on to its read delegation in situations where it
> just wants to make a small change to the file, and where that would not
> affect the caching behaviour of other clients.
> 
> Existing servers are, of course, not required to implement this new model,
> and remain compliant provided that they complied with the requirements in
> the original RFC3530.

Thanks for the succinct clarification.

Spencer