Remove issue with Vanilla install of Fedora 7

[Trond Myklebust]

On Thu, 2008-03-20 at 09:29 -0600, Christopher T Vogan wrote:
> I have been testing vanilla installs of Suse, Redhat and Fedora with
> NFSv4.
> I have stumbled upon a issue that I can not explain.
> The issue is the Linux client (Fedora 7) sends a CLOSE call. Before
> the server replies to the CLOSE the Linux client issue a rename. I
> wanted a remove I know why the linux client did that, it thinks the
> file is still open. What I do not understand is why did the Linux
> client not wait for the CLOSE call to reply before trying to remove
> the file?
> In this case the remove failed because of an invalid file name
> NAMETOOLONG which is expected in this case..
> 
> This issue does not happen on a system that has CITI kernel with
> patches and Userland utilities CITI provides. I am wondering if I have
> a configuration issue. I never saw this problem with prior or newer
> kernels. Is this something that the patched kernels resolve?
> 
> In the network trace (the part of interest):
> 
> CALL CLOSE
> CALL LOOKUP <- rename to replace remove
> REPLY CLOSE
> REPLY LOOKUP
> 
> 
> The test program does 4 things in this order to recreate this issue.
> OPEN fd
> STAT fd
> CLOSE fd
> REMOVE fd
> 
> 
> I gathered NFS client and RPC debug info and a network trace. I am
> also including a testcase to reproduce the problem.
> (See attached file: openclose.pcap)(See attached file:
> openclose.txt)(See attached file: openclose.c)
> 
> Christopher Vogan
> Dept. W98 NFS Development & Test 

That looks very much like the bug described in

 http://bugzilla.linux-nfs.org/show_bug.cgi?id=150

The fix was merged into 2.6.24-rc1. You can find it documented at

 http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git&a=commitdiff&h=a49c3c7736a2e77931dabc5bc4a83fb4b2da013e

Cheers
  Trond