linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.de>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	NFS <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH - RFC]  new "nosharetransport" option for NFS mounts.
Date: Tue, 9 Jul 2013 11:04:28 -0400	[thread overview]
Message-ID: <20130709150428.GA8281@fieldses.org> (raw)
In-Reply-To: <20130709132253.3dd4f90a@notabene.brown>

On Tue, Jul 09, 2013 at 01:22:53PM +1000, NeilBrown wrote:
> On Mon, 8 Jul 2013 18:51:40 +0000 "Myklebust, Trond"
> <Trond.Myklebust@netapp.com> wrote:
> 
> > On Mon, 2013-07-08 at 09:58 +1000, NeilBrown wrote:
> > > 
> > > This patch adds a "nosharetransport" option to allow two different
> > > mounts from the same server to use different transports.
> > > If the mounts use NFSv4, or are of the same filesystem, then
> > > "nosharecache" must be used as well.
> > 
> > Won't this interfere with the recently added NFSv4 trunking detection?
> 
> Will it?  I googled around a bit but couldn't find anything that tells me
> what trunking really was in this context.  Then I found commit 05f4c350ee02 
> which makes it quite clear (thanks Chuck!).
> 
> Probably the code I wrote could interfere.
> 
> > 
> > Also, how will it work with NFSv4.1 sessions? The server will usually
> > require a BIND_CONN_TO_SESSION when new TCP connections attempt to
> > attach to an existing session.

Since the current client only requests SP4_NONE state protection, the
BIND_CONN_TO_SESSION is implicit:

	If, when the client ID was created, the client opted for
	SP4_NONE state protection, the client is not required to use
	BIND_CONN_TO_SESSION to associate the connection with the
	session, unless the client wishes to associate the connection
	with the backchannel.  When SP4_NONE protection is used, simply
	sending a COMPOUND request with a SEQUENCE operation is
	sufficient to associate the connection with the session
	specified in SEQUENCE.

But Neil would need to make sure he's using all the state associated
with the existing client.

> Why would it attempt to attach to an existing session?  I would hope there
> the two different mounts with separate TCP connections would look completely
> separate - different transport, different cache, different session.
> ??

Sounds to me sharing these things shouldn't be a problem in your case,
but I don't know.

--b.

      parent reply	other threads:[~2013-07-09 15:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-07 23:58 [PATCH - RFC] new "nosharetransport" option for NFS mounts NeilBrown
2013-07-08 18:51 ` Myklebust, Trond
2013-07-09  3:22   ` NeilBrown
2013-07-09 10:01     ` NeilBrown
2013-07-09 14:21     ` Chuck Lever
2013-07-09 14:46     ` Myklebust, Trond
2013-07-09 15:04     ` J. Bruce Fields [this message]

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=20130709150428.GA8281@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).