DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2334C20657
MIME-Version: 1.0
References: <CAGD+tkyTyOb-iiykQLYMoa1h5cmizbe_0M0_HS=9cQC1NDznSw@mail.gmail.com>
 <24BEBD2F-BCC2-4AE0-81D7-185D6CAB8CD7@redhat.com>
In-Reply-To: <24BEBD2F-BCC2-4AE0-81D7-185D6CAB8CD7@redhat.com>
From:   Malahal Naineni <malahal@gmail.com>
Date:   Fri, 2 Nov 2018 21:24:36 +0530
Message-ID: <CAGD+tkzyDoq6tdseFQu4ymJCc-+-2i6XEUmBGKe4mu4_ngv7QA@mail.gmail.com>
Subject: Re: "(deleted)" directories
To:     bcodding@redhat.com
Cc:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

Ben, NFSv3 RFC1813.txt states: "If two file handles from the same
server are equal, they must refer to the same file, but if they  are
not equal, no conclusions can be drawn." Ganesha does return same
fileid here (inode).

In NFSv4, they have introduced "unique_handles" attribute. I don't see
Linux NFS client using this at all though.

Regards, Malahal.
On Fri, Nov 2, 2018 at 4:35 PM Benjamin Coddington <bcodding@redhat.com> wrote:
>
> On 2 Nov 2018, at 1:26, Malahal Naineni wrote:
>
> > Hi All, we are using NFS-Ganesha with Linux NFS clients. The client's
> > shell reports the following. Based on lsof, the directory is marked
> > deleted. "cd to ROOT and cd to the same home directory fixes the
> > issue. The client behaves as though the directory is deleted and
> > recreated! Our NFS-Ganesha server implementation uses multiple file
> > handles that point to the same object. NFS spec says this should be
> > fine, but Linux NFS seems to be broken in this regard. tcpdump does
> > indicate file handle change (note that all file handles are permanent,
> > meaning they are valid at the server any time) around this issue time.
> >
> > "shell-init: error retrieving current directory: getcwd: cannot access
> > parent directories: No such file or directory"
> > sh        112544            malahal  cwd       DIR               0,67
> >      65536   45605209 /home/malahal (deleted)
> > (10.120.154.42:/nfs/malahal-export/)
> >
> > Function nfs_prime_dcache() seems to invalidate the dcache entry if
> > nfs_same_file() returns false. nfs_same_file() does seem to return
> > false with the following change, if I read it correctly, if there is a
> > file handle change. Can this be the source of my issue? It seems that
> > the client should do this only if the file handle is NOT valid (e.g.
> > if it gets ESTALE), right?
> >
> > The following commit seems to assume that the objects are different if
> > they have different file handles!
> > commit 7dc72d5f7a0ec97a53e126c46e2cbd2560757955
> > Author: Trond Myklebust <trond.myklebust@primarydata.com>
> > Date:   Thu Sep 22 13:38:52 2016 -0400
> >
> >     NFS: Fix inode corruption in nfs_prime_dcache()
>
> My understanding is that for NFSv3 we have to assume that distinct
> filehandles are distinct objects, but maybe I'm wrong about this.
>
> For NFSv4.x, we can follow the guidance in RFCs 5661 or 7530 section 10.3.4
> to determine if the differing filehandles are the same object, specifically
> the fileid recommended attribute needs to be implemented.  Is Ganesha
> returning the same fileid for both filehandles?
>
> Ben