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

From: Rick Macklem <[email-masked]>
Date: Sun, 4 Jul 2010 12:28:01 -0400 (EDT)

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

---

From: Trond Myklebust <[email-masked]>
Date: Sun, 04 Jul 2010 12:24:32 -0400

> I don't think this is clarified in RFC3530, but please correct me if I'm

I read RFC3530 as being perfectly clear on this.

In section 9.4 it explicitly states that the client _cannot_ make any
changes to the contents or attributes of the file if it holds a read
delegation.

In section 9.4.4 it states that the server must recall the delegation in
the event of a conflicting OPEN or READ/WRITE w/ special stateids.

Cheers
  Trond

---

From: Rick Macklem <[email-masked]>
Date: Sun, 4 Jul 2010 19:54:08 -0400 (EDT)

> changes to the contents or attributes of the file if it holds a read

Ok, here are 2 paras from page 103:
    When a client has a read open 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 write open delegation,
    it may modify the file data since no other client will be accessing
    the file's data.  The client holding a write delegation may only
    affect file attributes which are intimately connected with the file
    data:  size, time_modify, change.

I see this as saying the read open delegation doesn't allow writing
to the file, but I don't see it saying "the client can't open the
file for writing against the server without first returning the
delegation". (Btw, I have no problem with it saying that, I just
didn't get that from the above para, especially given what it says
in the next para.)

    When a client has an open delegation, it does not send OPENs or
    CLOSEs to the server but updates the appropriate status internally.
-> For a read open delegation, opens that cannot be handled locally
    (opens for write or that deny read access) must be sent to the
    server.

I see "->" simply saying that the open has to be done against the
server. If the read open delegation must be returned for the open
to be done, shouldn't it state that explicitly.

> the event of a conflicting OPEN or READ/WRITE w/ special stateids.
If the open for writing is from the same client that holds the read open
delegation, it didn't hit me as a "conflict". I would have thought a
conflicting OPEN would have been one from a different client?

Isn't the english language wonderfully ambiguous?

If others feel the wording is clear, then I have no problem with it.
ie. If the client doesn't return the read open delegation before doing
     an open for writing against the server, the server will CBRECALL it.

rick

---

From: Trond Myklebust <[email-masked]>
Date: Sun, 04 Jul 2010 20:33:23 -0400

> conflicting OPEN would have been one from a different client?

The client is requesting access to do something which Section 9.4
expressly forbids it to do while holding a read delegation (i.e. to
write to/modify the file). How can that not be a conflict? RFC 3530
makes no difference anywhere between a client holding a read delegation
and requesting to change the file or any other client trying to do the
same. The result of any such request should be a recall if the client
has not already returned the delegation.

Now, once the delegation has been returned (or forcefully revoked), the
server is quite free to respond to the client's OPEN for write request
by handing out a write delegation, if the conditions allow for it...

Cheers
  Trond