Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
From: Olga Kornievskaia <aglo@umich.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Samy Ascha <samy@ascha.org>, linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: Specific IP per mounted share from same server
Date: Fri, 8 Nov 2019 12:06:00 -0500
Message-ID: <CAN-5tyGvLHJ2SJ2M56Ob3WRbbiG2-T1QYabgYY0EzbNB4h5DBg@mail.gmail.com> (raw)
In-Reply-To: <20191108162927.GA31528@fieldses.org>

On Fri, Nov 8, 2019 at 11:29 AM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Fri, Nov 08, 2019 at 11:09:10AM -0500, Olga Kornievskaia wrote:
> > Are you going against a linux server? I don't think linux server has
> > the functionality you are looking for. What you are really looking for
> > I believe is session trunking and neither the linux client nor server
> > fully support that (though we plan to add that functionality in the
> > near future).  Bruce, correct me if I'm wrong but linux server doesn't
> > support multi-home (multi-node?)
>
>
> The server should have complete support for session and clientid
> trunking and multi-homing.  But I think we're just using those words in
> slightly different ways:

By the full support, I mean neither client not server support trunking
discovery unless that sneaked in when I wasn't looking. That was the
piece that I knew needed to be done for sure.

When you say it fully support trunking do you mean it when each nfsd
node runs in its own container, right? Otherwise, I thought more code
would be needed to support the case presented here. nfsd would need to
have a notion of running something like a cluster node on a particular
interface and distinguish between requests coming from different
interface and act accordingly?

>
> > therefore, it has no ability to distinguish
> > requests coming from different network interfaces and then present
> > different server major/minor/scope values and also return different
> > clientids in that case as well. So what happens now even though the
> > client is establishing a new TCP connection via the 2nd network, the
> > server returns back to the client same clientid and server identity as
> > the 1st mount thus client will use an existing connection it already
> > has.
>
> So, this part is correct, it treats requests coming from different
> addresses the same way.
>
> Although you *can* actually make the server behave this way with
> containers if you run nfsd in two different containers each using one of
> the two network namespaces.
>
> There are also things the client could do to distribute traffic across
> the two IP addresses.  There's been some work on implementing that, but
> I've lost track of where it stands at this point....

Client can and will do trunking in case of pNFS to the data servers if
the server presents multiple IPs. Otherwise, we just have nconnect
feature but that doesn't split traffic between different network
paths.

>
> --b.

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  8:41 Samy Ascha
2019-11-08 16:09 ` Olga Kornievskaia
2019-11-08 16:29   ` bfields
2019-11-08 17:06     ` Olga Kornievskaia [this message]
2019-11-08 17:15       ` J. Bruce Fields

Reply instructions:

You may reply publically 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=CAN-5tyGvLHJ2SJ2M56Ob3WRbbiG2-T1QYabgYY0EzbNB4h5DBg@mail.gmail.com \
    --to=aglo@umich.edu \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=samy@ascha.org \
    /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

Linux-NFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \
		linux-nfs@vger.kernel.org
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git