Linux-NFS Archive on
 help / color / Atom feed
From: "J. Bruce Fields" <>
To: Olga Kornievskaia <>
Cc: Samy Ascha <>, linux-nfs <>
Subject: Re: Specific IP per mounted share from same server
Date: Fri, 8 Nov 2019 12:15:13 -0500
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Nov 08, 2019 at 12:06:00PM -0500, Olga Kornievskaia wrote:
> On Fri, Nov 8, 2019 at 11:29 AM J. Bruce Fields <> 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.

I'd also say that the client supports trunking discovery--in a way,
that's the source of the problem here.  The client is probing and
discovering that the two IP addresses point to the same server, and
using that information to share the same connection.  That's trunking
discovery, to my understanding.

> When you say it fully support trunking do you mean it when each nfsd
> node runs in its own container, right?

No, I mean that we support a client using multiple sessions (clientid
trunking), or multiple connections per session (session trunking).

> 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?

I guess it'd be possible to do something like that.  For now we don't
have any plans outside of the namespace/container work.  I wouldn't call
that trunking support.

But I think we agree on what's actually supported and not supported
here, we just disagree about the meanings of words like "trunking

> 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.

Got it, thanks.


  reply index

Thread overview: 6+ 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
2019-11-08 17:15       ` J. Bruce Fields [this message]
2019-11-18 10:08       ` Samy Ascha

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-NFS Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone