Remove issue with Patch Kernel 2.6.25-rc9-CITI_NFS4_ALL-1

[Trond Myklebust]

On Tue, 2008-07-22 at 14:42 -0600, Christopher T Vogan wrote:
> Trond,
> I think I am seeing the remove issue again on a system with a patched
> CITI kernel 2.6.25-rc9-CITI_NFS4_ALL-1.
> I have a C program that issues:
> Open 
> Stat 
> Close 
> Remove 
> 
> The remove never gets sent, instead the client wants to rename the
> file to .nfs000000009b331bb0000000b2 . This fails for us since we can
> not have a name greater then 8 chars, including the leading period on
> zOS.

This is a client bug. We shouldn't be trying to use long names if the
server advertises that it only supports short ones...

> I am trying to understand why the linux client want to rename the file
> in the first place.
> See the attached network trace. 
> 
> Basicly this is whats going on.
> Frame 139 Close Call 
> Frame 140 Lookup .nfs000000007b9ee00d000000b5 <-- why did you not wait
> for the close reply?
> Frame 141 TCP packet
> Frame 142 Lookup Reply NFS4ERR_NAMETOOLONG <-- we can except this, its
> not an error on the server. 
> Frame 143 Close reply NFS_OK
> 
> 
> This test showed that the Linux Client did not wait for the server to
> reply to the close. This is the same error I had reported before. See
> notes below.

This seems odd... Commit a49c3c7736a2e77931dabc5bc4a83fb4b2da013e should
in principle ensure that we always wait for the CLOSE to complete as we
go through nfs_release(). Any idea why it is failing?

Cheers
  Trond