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

[<[e-mail]>]

I can see that this is clearly stated but I'm coming to the conclusion that it is a mistake.

I don't know that means it is an erratum that can be fixed in a bis, but I do think
We should be thinking about whether the protocol should work that way, and think
about what we want to do about this in v4.x going forward.

When I get a read delegation, I'm assured that nobody else is changing the file.

I don't need an assurance that I'm not changing the file.  I know whether I'm changing
the file.   

It could be that this restriction helps the others who have a read delegation but it
doesn't.  If I had no delegation, then when I opened for write, all of clients 
Holding read delegations would have their delegations recalled.  That make sense.

Now if I also hold a read delegation, then the spec says, as Trond points out,
That I will lose mine as well.  The question is "why?"  It can't be to inform me
that I'm writing.  I know that.

The problem here is that the protocol as now specified, cannot give you a delegation-based
assurance that you are the only one writing.  You can get an open-based non-revocable
assurance that you are the only writer by opening for write with deny-write, but
it is anomalous that you can't get a delegation-style assurance of this.

I accept that the spec says this clearly but does anybody know any good reason that it
should say that?  If it didn't, would the protocol be more or less useful?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Trond Myklebust
Sent: Sunday, July 04, 2010 8:33 PM
To: Rick Macklem
Cc: [e-mail]
Subject: Re: [nfsv4] can a server replace a read deleg with a write deleg?

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

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4