From: Trond Myklebust <trondmy@hammerspace.com>
To: "mbenjami@redhat.com" <mbenjami@redhat.com>
Cc: "bcodding@redhat.com" <bcodding@redhat.com>,
"malahal@gmail.com" <malahal@gmail.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: "(deleted)" directories
Date: Sat, 3 Nov 2018 00:15:42 +0000 [thread overview]
Message-ID: <a45a428ad45e5834fa7030088a75275584b13ab2.camel@hammerspace.com> (raw)
In-Reply-To: <CAKOnarkG4tpA7F306hgpk14XNELEFY1gaY7=QY4h6Dr-zSQzRw@mail.gmail.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
next prev parent reply other threads:[~2018-11-03 0:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 5:26 "(deleted)" directories Malahal Naineni
2018-11-02 11:05 ` Benjamin Coddington
2018-11-02 15:54 ` Malahal Naineni
2018-11-02 20:26 ` Trond Myklebust
2018-11-02 22:07 ` Matt Benjamin
2018-11-03 0:15 ` Trond Myklebust [this message]
2018-11-03 2:38 ` Marc Eshel
2018-11-03 3:27 ` Trond Myklebust
2018-11-03 3:37 ` Marc Eshel
2018-11-04 5:31 ` NeilBrown
2018-11-04 19:47 ` Marc Eshel
2018-11-05 0:32 ` NeilBrown
2018-11-05 4:41 ` Malahal Naineni
2018-11-05 5:09 ` NeilBrown
2018-11-05 7:40 ` Malahal Naineni
2018-11-05 13:45 ` Trond Myklebust
2018-11-05 23:49 ` NeilBrown
2018-11-06 0:37 ` Trond Myklebust
2018-11-06 8:43 ` Mkrtchyan, Tigran
2018-11-06 19:25 ` Bill Baker
2018-11-06 22:17 ` Rick Macklem
2018-11-05 4:48 ` Marc Eshel
2018-11-03 5:00 ` Malahal Naineni
2018-11-03 5:40 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a45a428ad45e5834fa7030088a75275584b13ab2.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=bcodding@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=malahal@gmail.com \
--cc=mbenjami@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).