All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Bruce Fields'" <bfields@fieldses.org>,
	"'Daire Byrne'" <daire@dneg.com>
Cc: "'Chuck Lever III'" <chuck.lever@oracle.com>,
	"'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>
Subject: RE: [PATCH] nfs: reexport documentation
Date: Wed, 22 Sep 2021 07:40:21 -0700	[thread overview]
Message-ID: <01ca01d7afbf$c59723f0$50c56bd0$@mindspring.com> (raw)
In-Reply-To: <20210922142655.GA22937@fieldses.org>

> On Wed, Sep 22, 2021 at 10:47:35AM +0100, Daire Byrne wrote:
> > We don't use or need crossmnt functionality, but I know from chatting
> > to others within our industry that the fsid/crossmnt limitation causes
> > them the most grief and confusion. I think in the case of Netapps,
> > there are similar problems with trying to re-export a namespace made
> > up of different volumes?
> >
> > As noted on the wiki, the only way around that is probably to have a
> > "proxy" mode (similar to what ganesha does?).
> 
> I'm not sure what Ganesha does.  I spent some time thinking about and
couldn't
> figure out how to do it, at least not on my own in a reasonable amount of
time.
> 
> I liked the idea of limiting the proxy to reexport only one original
server and
> reusing the filehandles from the original server without any wrapping.
That
> addresses the fsid/crossmnt limitation and filehandle length limitations.
It
> means proxies all share the same filehandles so eventually you could also
> implement migration and failover between them and the original server.
> 
> It means when you get a filehandle the only way to find out *anything*
about it-
> -even what filesystem it's from--is to go ask the server.
> That's slow, so you need a filehandle cache.  You have to deal with the
case
> where you get a filehandle for an object that isn't mounted yet.
> Its parents may not be mounted yet either.  If it's a regular file you
can't call
> LOOKUPP on it.  I'm not sure how to handle the vfs details in that
case--how do
> you fake up a superblock and vfsmount?

That really highlights how Ganesha's proxy is different than anything knfsd
would do. Ganesha doesn't have to deal with all the vfs stuff. It just needs
to be able to reflect the original server's handle back to the original
server. Ganesha ONLY supports NFSv3 proxy (without file open) and NFSv4.1+
proxy since it needs open by handle. Ganesha then lives with totally
floating inodes. They may get connected in a name space as a result of
READDIR or LOOKUP but it never needs the name space. Changing knfsd to NOT
need to hook the proxied server's handles into vfs would just result in a
kernel implementation of something more like Ganesha and probably not worth
it.

> Simpler might be to give up on that idea of reusing the original server's
> filehandle, and automatically generate and persistently store uuids for
new
> filesystems as you discover them.

Ganesha does have a mode for proxy where it uses a database to map original
server handles and Ganesha handles. That helps get around file handle size
problems but it's not a great solution because you have to keep a persistent
data base or lose it all when the proxy crashes.

Frank



  reply	other threads:[~2021-09-22 14:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21 14:32 J. Bruce Fields
2021-09-21 14:39 ` Chuck Lever III
2021-09-21 16:00   ` Bruce Fields
2021-09-22  9:47     ` Daire Byrne
2021-09-22 14:26       ` Bruce Fields
2021-09-22 14:40         ` Frank Filz [this message]
2021-09-22 14:32       ` Frank Filz

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='01ca01d7afbf$c59723f0$50c56bd0$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=daire@dneg.com \
    --cc=linux-nfs@vger.kernel.org \
    --subject='RE: [PATCH] nfs: reexport documentation' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.