Re: [PATCH] nfs: don't queue synchronous NFSv4 close rpc_release to nfsiod

[Jeff Layton <jlayton@redhat.com>]

On Thu, 17 Feb 2011 08:40:52 -0500
Jeff Layton <jlayton@redhat.com> wrote:

> 
> Looks like it finally failed on the 39th pass:
> 
> second check for lost reply on non-idempotent requests
> testing 50 idempotencies in directory "testdir"
> rmdir 1: Directory not empty
> special tests failed
> 
> When I look in the directory (several hours after it failed), the
> silly-renamed file is still there:
> 
> -rw---x--x. 1 root root   30 Feb 16 15:04 .nfs000000000000002d00000090
> 
> ...so I'm not sure what exactly is wrong yet, but it looks like the
> silly delete just never happened. Maybe there's a dentry refcount leak
> of some sort? There are no queued RPC's.
> 
> I'll keep looking at it but if you have ideas as to what it could be,
> let me know.
> 

I walked down the directory tree in crash on the live kernel and found
the dentry. The d_count is 0x0, so I'm not clear on why it didn't get
cleaned up:

crash> struct dentry.d_flags,d_count,d_name 0xffff880017d46a80
  d_flags = 0xc000, 
  d_count = 0x0, 
  d_name = {
    hash = 0xe08ab5c8, 
    len = 0x1c, 
    name = 0xffff880017d46ab8 ".nfs000000000000002d00000090"
  }, 


The d_flags are:

#define DCACHE_OP_REVALIDATE    0x4000
#define DCACHE_OP_DELETE        0x8000

...very odd. I'd have expected to see this one set too:

#define DCACHE_NFSFS_RENAMED  0x0002

I suppose the async sillyrename call could have failed and we ended up
calling nfs_cancel_async_unlink? I'll stick in some printk's around
that area and see if I can figure out what's going on...

-- 
Jeff Layton <jlayton@redhat.com>