Subject: RE: [nfsv4] Open/CBGetattr scenario

From: Peter Varga <[email-masked]>
Date: Thu, 9 Mar 2006 17:53:14 -0500

This is getting ridiculously complex. This is why I am campaigning that the
delegation should simply be recalled, and in this case, with the truncate
flag set in the recall. If you want, you can give the delegation again in
the second OPEN.

If you implement your suggestions, imagine the fun the novice programmer who
will one day take on your job is going to have trying to understand what all
those if()s are for in the code :)

Actually the conclusion to the previous thread was that the server can do
whatever it wants with the second open except return an error. That's not a
very good conclusion, but that's where we left it off.

Now if we followed my original suggestion and recalled the delegation, none
of this would be an issue. The client would return the delegation, and then
the file could be truncated.

I really don't think CB_GETATTR was ever supposed to be sent to the client
holding the delegation. And, you can't count on the clientid being in the
same compound.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 5:33 PM
To: [email-masked]
Subject: [nfsv4] Open/CBGetattr scenario

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

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

---

From: [email-masked]
Date: Fri, 10 Mar 2006 11:44:52 -0500 (EST)

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

As I just mentioned in the other post, I'm hoping that the client
implementors will stand up and say they don't mix ops for multiple
clients. I think I will go ahead and implement "implied clientid for
a compound" in my server and use it to decide of Callbacks are required.

> Er, how will the server respond to the NFS4ERR_BAD_HANDLE?

When a CBGetattr fails, my server just returns its notion of the attributes
for the Getattr Op. (I think this covers the case where the client hasn't
yet processed the reply with the Write Delegation in it and another compound
with a Getattr Op has shown up at the server. In the worst case, this can
come from another client or in a compound with no clientid in any of the Ops,
so it can still occur even with "implied clientid for the compound".

rick