Subject: Re: [nfsv4] Open/CBGetattr scenario

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

[Spencer wrote]
> 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

Dave makes a good argument for not doing CBGetattr when the Write Delegation
does not allow the file to grow (which is what my server is doing at this
point). However, I would have assumed such a Write Delegation would
still allow the client to truncate the file locally, if it wished to do
so. I suspect that current ones do a Setattr with Size or Open/Create
right away, but couldn't a client delay doing this until Delegreturn?

If clients always do Truncation to the server without delay, then I'd agree
that the CBGetattr is not required for the Write Delegations that don't
allow files to grow. (I'd also like to see Write Delegations that allow
files to grow work properly, since I think they could be a big performance
win, if clients use them properly.)

If course, as Dave also notes, since this isn't in the RFC, it's hard to
argue that an nfsv4.0 server shouldn't do CBGetattrs for this case, just
that the server doesn't have to.

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

My server does recognize the "special case" of a Getattr in the same
compound as the Open that is being issued the Delegation and doesn't
do the CBGetattr for that case. It is for Getattrs that show up later,
that I do the CBGetattr. (I wasn't aware of Dave's post until now.)

I'd like to make the more general assumption of "same clientid within
compound", but I would like the client implementors to stand up and
say "we never do Ops for different clients in the same compound", so I
know that's ok.

And, yes, I think that having a Getattr Size after the Open in the same
compound, is the best way for the client to get an initial value of Size.
Once it "knows" the file's size, I still believe it should ignore any
subsequent Getattr Size replies until it does Delegreturn.

I'm going to think about the "implied clientid" due to being in the
same compound. This would allow avoidance of the CBGetattr for that
case.

The last sentence of Sec. 9.4.3 seems to imply that the server has the
choice of doing the CBGetattr or Recalling the delegation. Although I
understand why Peter feels the Recall is a good idea. I'm still trying
to leave that as a last resort.

rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 24 Mar 2006 16:49:47 -0600

> that the server doesn't have to.

I have created an issue to update the 4.1 I-D with the interpretation
of CB_GETATTR and implied clientid use.

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue32

Spencer