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

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 24 Mar 2005 11:29:38 -0500

Spencer wrote:

>   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.

The spec says:

   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.

I'm assuming (in the interests of sanity) that changing the access time
by reading the file is not included.  It doesn't seem to me that there's
a big problem with recalling the delegation when system, hidden,
mime_type,
etc are set.

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.

Now read literally this seems to say that the only the delegation holder
cannot change the attributes (and that possibly other clients can).
That
last part doesn't really make sense.  Since a write delegation is
stronger
than a read delegation, and if the read delegated client can assume
nobody
else is changing attributes, it would seem that the write delegated
client
should be able to also to assume that nobody else is changing
atrributes,
and I can't see why he should be barred from changing them either, just
as clients can when there are no delegations out.

So this looks to me like a mistake, or a set of mistakes, but not
errata.
If I recall correctly I wrote this.  I think what I must have intended
was 
to say that with a write delegation you cannot hold back on attribute
updates 
(as you can with data), but that isn't what came out.

So I think the way it should work is:

     1) If you have a read delegation you may not change attributes.

     2) If someone else has a read delegation you are assured that other
     people cannot change attributes (except access time) until your
     delegation is returned.

     3) If you have a write delegation you may change attributes but you

     should note that other people may read them despite your delegation
     so you may not hold attribute updates until delegation recall as 
     you can with data updates.

     4) When you hold a write delegation you are assured that other
     people cannot change attributes until your delegation is returned.

     5) When you issue a SETATTR holding a (write) delegation, the
stateid 
     should be the delegation stateid.

     6) When a SETATTR is done and read delegations are held the server
     must recall them and not do the attribute change until they are
     returned or revoked.

     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.

The problem squaring this with the spec.  

     1), 2) is in the spec. and they, together with the spec's approach 
     to delegation handling imply 6)

     4) is a reasonable inference from 1) and 2) given the basic
strength
     relationships among delegations types.

     5) is a reasonable practice and the spec seems to allow it.

     3) and 7) are the problem.  I guess I can argue that in,

   The client holding a write delegation may only
   affect file attributes which are intimately connected with the file
   data:  size, time_modify, change.

"may only" is not equal to "MUST only" or even "SHOULD only".  The spec
doesn't seem to say what happens if you try.  The interesting fact is
that the only way the server can really know if you are the client is
through the stateid, so it seems to be be saying that if use a zero
stateid I can do the SETATTR, whereas if I use the delegation stateid
I "may not".  But if so, what does the server do?  Recall the delegation
stateid that I just handed you?  It doesn't specifically say that.
So I guess I have to argue that 4) gives me the license to recall for
a zero stateid and the fact that I (as a server) don't recall the 
delegation when the delegation stateid is used is not something that
is contradicted by the spec.  As for the "may not" that applies to
the client, but what is the client to do if he takes seriously, 
return the delegation before doing the SETATTR.  That would stink.

It seems, at least to me, that we have a clear mistake here.

Other opinions?

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Monday, March 21, 2005 5:30 PM
To: [email-masked]
Subject: Re: [nfsv4] Recalling write delegations on setattr

On Mon, Khan, Saadia wrote:
> > > an open that never went OTW (since it had a delegation), 
> > and the setattr 
> > > would change it such that a future recovery reopen OTW would fail.

> > > Forcing the internal open OTW, then doing the setattr will prevent

> > > possible breakage.
> > > 
> > > So from the server's point of view, it should issue a CB_RECALL
for
> > > setattrs on mode (regardless if the stateid is special or 
> > delegation).
> > 
> > The reclaim issues still exist without delegations being present in 
> > that the client will attempt to reopen a file that has 
> > potentially had a acl/mode change that would now disallow the 
> > OPEN from succeeding.
> > 
> > I think the more salient point is that the delegation allows 
> > the client to use ACCESS to determine if an OPEN would pass 
> > the ACCESS test at the server and then proceed.  The client 
> > is able to cache the ACCESS results and use them in the 
> > future while it has the delegation. If the server is 
> > processing a acl/mode change, it should recall the delegation 
> > as a means to "flush" the ACCESS cache at the client and 
> > force it to OPEN to the server for existing and future OPENs. 
> > Once the acl/mode change is complete, then the server can 
> > provide a delegation and the client can go back to using 
> > ACCESS to determine appropriate OPEN processing under that 
> > delegation, etc.
> > 
> 
> What about changes to owner/group then? Those should also cause a
> recall. So is it safe to say that setattr operations other than the
ones
> that change the owner/group/mode/acl should not cause a delegation to
be
> recalled?

Yes, owner and owner_group fall into the same category as mode/acl.

It is my opinion that setattr of attributes other than 
owner/owner_group/mode/acl do not require a recall of the delegation.

Spencer

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 Mar 2005 12:07:37 -0500

>      you can with data updates.

I assume you are excluding file size (and change_attr) from the list of
attributes that should be synchronous? The server has CB_GETATTR for
dealing with those two.

>      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.

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.

on page 207. That whole section is going to need a major rewrite...

Cheers,
  Trond
-- 
Trond Myklebust <[email-masked]>