Subject: RE: [nfsv4] Open/CBGetattr scenario

From: Peter Varga <[email-masked]>
Date: Fri, 10 Mar 2006 09:34:23 -0500

Although sending of CB_GETATTR is causing problems in Rick's scenario, I
don't think it is the root of the problem: the second OPEN from the client
that has the write delegation has the create flag set! Such an OPEN, if
successful (and it is in this case), must change the value of the 'change'
attribute, thereby necessitating a delegation recall in this case.

Peter

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 6:55 PM
To: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Open/CBGetattr scenario

--- [email-masked] wrote:

> Although it seems like "bad form" for a client to do a Getattr for Size
> when it has a Write Delegation, there could be cases like Trond mentioned,

At first I was wondering ifr you mean the case of a GETATTR after an OPEN,
but whether you meant it for all GETATTRs or not, I'm wondering how a client
that
opens a file and gets a write delegation can ever get the the initial file
size and change attribute atomically? Unless the server
recognizes the GETATTR done in the same COMPOUND after an operation
that uses is the same client, the server will have to a CB_GETATTR, and
the client will have no idea what to return. 

So I think you should recognize that the GETATTR in your scenario is from
the same clientid, and skip the CB_GETATTR.

> where another Open (different open_owner) is issued before the reply with
> the Write Delegation is processed.
> 
> It seems to me that the solution is for the client to simply ignore any
> Size replied in a Getattr when it has a Write Delegation, while
maintaining
> it own file size.
> - If the client gets a CBGetattr before processing the Open reply with the
>   Write Delegation in it, the CBGetattr should fail with
NFS4ERR_BAD_HANDLE
>   and the server can return its idea of the Size (0 in this case).
> - If the client has the Write Delegation, then the CBGetattr will work,
>   but the client should ignore the Size value in the reply and use its
>   own size (which it would set to 0 when it sees the NFS_OK reply to
>   Open/Create).
> 
> Does this all make sense, or is what went across the wire bogus? rick
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
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: Fri, 10 Mar 2006 10:09:48 -0500

> attribute, thereby necessitating a delegation recall in this case.

Why? I agree that putting two create requests on the wire for the same
file at the same time is a strange thing to do.

However this is the client that holds the delegation. Which of the
recall cases in section 9.4.4 applies? (other than "the server may
choose to recall open delegations at any time" ;-))

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Fri, 10 Mar 2006 07:23:59 -0800 (PST)

> attribute, thereby necessitating a delegation recall in this case.

The presence of the create flag is set 
to open and create an existing
file does not alter the change attribute.

However, the presence of the attributes 
in the OPEN operation that set the
file size to zero bytes does result 
in the value of 'change' changing.

Regardless, this does not require a recall. 
For one thing, this OPEN for create/truncate
might very well be one that the client did 
ages ago in its own cache, and it is
now flushing it to the server for whatever 
reason. For another thing, the server might have 
already recalled the delegation, and the client is
flushing for that reason.

Clients that hold delegations are free 
to send OPENs, LOCKs, SETATTRs, WRITEs etc. whenever
they want. That's why these operations include stateids.