Re: "(deleted)" directories

[Trond Myklebust <trondmy@hammerspace.com>]

On Fri, 2018-11-02 at 18:07 -0400, Matt Benjamin wrote:
> It sounds like a pretty good one, that goes to the heart of what a
> specification is
> 

While admittedly it is (still) Dia de los Muertos today, I would think
that someone who resurrected a part of the NFSv3 spec that has been
unused for the full 23 years of its existence might have some
explanation for why they did so?

IOW: not being of a particularly religious persuasion, I usually want
to understand why features are needed rather than having blind faith in
the person who wrote the spec.

> Matt
> 
> On Fri, Nov 2, 2018 at 4:26 PM, Trond Myklebust <
> trondmy@hammerspace.com> wrote:
> > On Fri, 2018-11-02 at 21:24 +0530, Malahal Naineni wrote:
> > > 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.
> > 
> > Why does your server need to have multiple filehandles refer to the
> > same file, and why do you expect clients to support this?
> > 
> > Yes, the spec allows it, but that's not a sufficient reason.
> > 
> > > 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
> > --
> > Trond Myklebust
> > CTO, Hammerspace Inc
> > 4300 El Camino Real, Suite 105
> > Los Altos, CA 94022
> > www.hammer.space
> > 
> > 
> 
> 
-- 
Trond Myklebust
CTO, Hammerspace Inc
4300 El Camino Real, Suite 105
Los Altos, CA 94022
www.hammer.space