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

[Trond Myklebust <[e-mail]>]

On Sun, 2010-07-04 at 19:54 -0400, Rick Macklem wrote:
> 
> On Sun, 4 Jul 2010, Trond Myklebust wrote:
> 
> >
> > 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.
> >
> 
> 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.
> 
> > 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.
> >
> 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?

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