Subject: [nfsv4] Open/CBGetattr scenario

From: [email-masked]
Date: Thu, 9 Mar 2006 17:32:35 -0500 (EST)

Ok, here's the scenario I saw at Cthon06. (I'll admit the server is mine,
the client shall remain anonymous:-) It occurred for Cthon basic "test5 -t":
	- Client Opens "bigfile" with Create/Claim_null, gets Open and
		Write Delegation stateids
	- write, ..., write, commit, close
	- Now the Client Opens "bigfile" with Create/Claim_null and follows
		it with a Getattr for Size, etc. in the same compound
	- Server does Open (truncates file to 0 length)
	- For Getattr:
		- Server does CBGetattr to Client for Size, Change
		- Client Replies to CBGetattr with Size == 1048576
	- Server replies NFS_OK to the compound, returning 1048576 for Size
		in the Getattr reply

this reply with Size != 0 gets the client to fail the test.

When I first saw this, it looked pretty weird, but I can't see anything
wrong with what went over the wire.
(I wasn't sure about my handling of the 2nd Open, but that's already been
resolved in the previous thread.) Given what is said near the top of
Page 109:
      return to client (that sent GETATTR) the attributes
         it requested, but make sure size comes from what
         CB_GETATTR returned.  Do not update the file's metadata
         with the client's modified size.

it does seem correct for the server to return 1048576 for Size and not 0
in the Getattr reply. It would be nice if the server knew it was the same
client, so that it could avoid the CBGetattr, but without a clientid arg.
in Getattr, we're back to what Bruce mentioned w.r.t. "same clientid
applies to the entire compound". This doesn't seem to be stated anywhere
in the RFC. Can a server safely assume this?

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Mar 2006 17:22:41 -0600

> in the RFC. Can a server safely assume this?

I should hope clients don't mix ops for multiple clientids in one
compound, even implementations that did one-clientid-per-user probably
wouldn't do this since that would mean batching ops/transactions into a
single compound when it'd be easier to let TCP do its thang.

Maybe we need a PUTCLIENTID...

>   and the server can return its idea of the Size (0 in this case).

Er, how will the server respond to the NFS4ERR_BAD_HANDLE?

>   own size (which it would set to 0 when it sees the NFS_OK reply to

This one makes sense.  This problem is really local to the client.

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 Mar 2006 17:43:29 -0600

I will refer to the previous thread on this topic. Specifically this message
from Dave Noveck:

http://www.nfsv4.org/nfsv4-wg-archive-feb-03-feb-05/0143.html

In essence, CB_GETATTR is not used when a write delegation is provided
that has no space guarantees.  

Also discussed is the ability of the server to "capture" the clientid
in the processing of the COMPOUND and using that value to determine if
it needs to contact the client since it is the one that holds the
delegation.

As Dave suggests in his original email, both should be clarified in 4.1.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Thu, 9 Mar 2006 15:55:26 -0800 (PST)

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Mar 2006 19:02:30 -0500

> the same clientid, and skip the CB_GETATTR.

Yep. The result of a GETATTR call that was made before the client gets
the delegation can hardly be trusted as being authoritative in a
CB_GETATTR call by the server.

Cheers,
  Trond