Subject: RE: [nfsv4] Recalling write delegations on setattr

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 1 Apr 2005 07:15:46 -0500

Rick wrote:

> [Dave wrote]
> > It also says:
> > 
> >    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.
> Would replacing the last sentence with something like:
>      The client holding a write delegation may only locally modify file
>      attributes which are intimately connected with the file data:
>      size, time_modify , change. The client must immediately do a
>      Setattr Op to change any other attributes for the write delegated file.
> be sufficient, as a clarification of what you meant?

Yes.

> [stuff snipped]
> [Trond wrote]
> >      7) When a SETATTR is done and a write delegation is held, the
> > server
> >      must recall if and only if the stateid passed is not that of the
> >      write delegation.  When it is not, the write delegation must be
> >      recalled and the attribute change must not proceed until the
> >      delegation is returned or recalled.
> > 
> > If I have OPENed the file for writing, why shouldn't I be able to use
> > the resulting open_owner stateid? After all, I can do that for ordinary
> > writes without having the write delegation recalled.

> Unless the RFC is re-written, it would seem that an open stateid should be
> sufficient. In other words, the server should be able to discern that the
> client with that open stateid also holds a write delegation for the same
> file. If not, the server is forced to recall the delegation?

First, I agree that write and SETATTR's need to be handled exactly the same
in this regard.

Also, I agree that if you have a stateid that is sub-ordinate to the delegation,
i.e. recieved with the delegation or obtained from a DLGCUR OPEN specifying
that delegation, then that open stateid should serve the purpose just as well.

The interesting case is if the client can have an OPEN that is not sub-ordinate
in that way to the delegation, at the same time as it has the delegation.  My
assumption has been that that case can't exist and the server would not give
out a delegation when there were other conlficting open's about, even if they
were for the same client.

When I wrote up the delegation stuff, my mental model was that a strong 
distinction would be made between stateid's that were sub-ordinate to a 
delegation (in the sense above) and those that were not.  Even though the
server knew that it was the same client, I was worried that allowing this
might mean that it in the presence of various message crossings, there to
be a disagreement between client and server about the actual state of
affairs relative to the delegation.  In other words, I was worried that
in Heraclitus's (wasn't he the you-can't-step-in-the-same-river-twice 
guy?) sense, the client that issued the non-delegation-associated open 
and the one that got the delegation were not the same (although there is
obviously a continuity between them). 

But looking at the text, I can't find any place where this vision is really
communicated, except inferentially (in that if you simply expected that
simply matching clientid to always work with no isssues, DLGCUR open 
would not be needed).  Further, I haven't really come up with a case in
which the issues I worried about would be troublesome (but I haven't
really been trying).

Anyway, I think it is fair to say that if a server allows there to exist
on the same client a stateid that is not manifestly delegation-associated
and a delegation at the same time, it is OK with this situation and so
it has to be prepared to accept that stateid in this context.

> > You're also in major conflict with the main paragraph describing
> > SETATTR:
> > 
> >    The stateid argument for SETATTR is used to provide file locking
> >    context that is necessary for SETATTR requests that set the size
> >    attribute.
> >    ..... When the file size attribute is not set, the special
> >    stateid consisting of all bits zero should be passed.
> 
> I do feel this is "errata" that needs to be changed. 

It is certainly a mistake, and I feel it needs to be addressed somehow.

People with delegations do sometimes have to change attributes and if
they do and the stateid is zero, how does the server know not to recall
the delegation?  If it does recall it, performance suffers.

What is "errata" is really unclear.  When Spencer sent out his message
about gathering errata, he sent an IETF link to an errata list which 
confused me.  Most of the things I looked at were of the change-"a"-to-
"an" variety and there was this statement that was something like
"anything that changes the sense of the text will not be posted".
This raises the question of how you can fix a mistake, i.e. something
where the sense of the existing text is *wrong*, without changing
the sense of the text?  Why have an errata process if you can't fix
mistakes?  There was also some stuff on this site that talked about 
carefully everything was proofread with the implication being "we don't
make mistakes" which gets back to issue of why have an errata process.
Is it for the "a"-vs-"an" stuff?  Do people really need a site to go
to when they note an error of this sort?  If it is posted there, they
can note it is posted there and if it isn't they can note that it isn't
posted there.  They won't code their implementation any differently.

It seems that this is for the benefit of people who have a lot more free 
time that most of us.  Maybe they should use that time better: play video 
games, do crossword puzzles, go out and get drunk ... :-) 
 
> I think the stateid
> of all 0s should only be used when the client doesn't have a write
> delegation.

I agree.

> Maybe change the last sentence to something like:
>     ... all bits zero should be passed, unless the client has a write
>     delegation. For that case, the write delegation stateid should be
>     used.

But that implies that the spec is wrong.  I understand it was very 
carefully proofread, so that can't be possible :-)

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Apr 2005 22:56:51 -0700

> posted there.  They won't code their implementation any differently.

My plan is that errata will be small changes that are clear and
easily included in the errata page by the RFC editor.  What is that?
I am not sure so it will be judgement call on my part.

For the larger items, I am not opposed to having specific clarification
I-Ds (that turn into standards track RFCs) which cover larger
discussions or clarifications.  These could be 2-5 pages and
cover all known issues or interpretations in an area.  The example
we have of that is the repl/migr interpretations.

An errata draft is still forthcoming.  Most likely the week after
next (after Usenix).

Spencer