From: Steve Dickson <SteveD@RedHat.com>
To: NeilBrown <neilb@suse.com>, Chuck Lever <chuck.lever@oracle.com>,
Olga Kornievskaia <aglo@umich.edu>
Cc: Anna Schumaker <Anna.Schumaker@netapp.com>,
Trond Myklebust <trondmy@hammerspace.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/9] Multiple network connections for a single NFS mount.
Date: Wed, 12 Jun 2019 08:39:28 -0400 [thread overview]
Message-ID: <e4b6f790-c87c-5839-2de5-67ec561cda3d@RedHat.com> (raw)
In-Reply-To: <877e9rwuy5.fsf@notabene.neil.brown.name>
On 6/11/19 7:42 PM, NeilBrown wrote:
> On Tue, Jun 11 2019, Chuck Lever wrote:
>
>>
>> Earlier in this thread, Neil proposed to make nconnect a hint. Sounds
>> like the long term plan is to allow "up to N" connections with some
>> mechanism to create new connections on-demand." maxconn fits that idea
>> better, though I'd prefer no new mount options... the point being that
>> eventually, this setting is likely to be an upper bound rather than a
>> fixed value.
>
> When I suggested making at I hint, I considered and rejected the the
> idea of making it a maximum. Maybe I should have been explicit about
> that.
>
> I think it *is* important to be able to disable multiple connections,
> hence my suggestion that "nconnect=1", as a special case, could be a
> firm maximum.
> My intent was that if nconnect was not specified, or was given a larger
> number, then the implementation should be free to use however many
> connections it chose from time to time. The number given would be just
> a hint - maybe an initial value. Neither a maximum nor a minimum.
> Maybe we should add "nonconnect" (or similar) to enforce a single
> connection, rather than overloading "nconnect=1"
>
> You have said elsewhere that you would prefer configuration in a config
> file rather than as a mount option.
> How do you imagine that configuration information getting into the
> kernel?
> Do we create /sys/fs/nfs/something? or add to /proc/sys/sunrpc
> or /proc/net/rpc .... we have so many options !!
> There is even /sys/kernel/debug/sunrpc/rpc_clnt, but that is not
> a good place for configuration.
>
> I suspect that you don't really have an opinion, you just don't like the
> mount option. However I don't have that luxury. I need to put the
> configuration somewhere. As it is per-server configuration the only
> existing place that works at all is a mount option.
> While that might not be ideal, I do think it is most realistic.
> Mount options can be deprecated, and carrying support for a deprecated
> mount option is not expensive.
>
> The option still can be placed in a per-server part of
> /etc/nfsmount.conf rather than /etc/fstab, if that is what a sysadmin
> wants to do.
+1 making it per-server is the way to go... IMHO...
steved.
next prev parent reply other threads:[~2019-06-12 12:39 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 0:41 [PATCH 0/9] Multiple network connections for a single NFS mount NeilBrown
2019-05-30 0:41 ` [PATCH 2/9] SUNRPC: Allow creation of RPC clients with multiple connections NeilBrown
2019-05-30 0:41 ` [PATCH 9/9] NFS: Allow multiple connections to a NFSv2 or NFSv3 server NeilBrown
2019-05-30 0:41 ` [PATCH 4/9] SUNRPC: enhance rpc_clnt_show_stats() to report on all xprts NeilBrown
2019-05-30 0:41 ` [PATCH 5/9] SUNRPC: add links for all client xprts to debugfs NeilBrown
2019-05-30 0:41 ` [PATCH 3/9] NFS: send state management on a single connection NeilBrown
2019-07-23 18:11 ` Schumaker, Anna
2019-07-23 22:54 ` NeilBrown
2019-07-31 2:05 ` [PATCH] NFS: add flags arg to nfs4_call_sync_sequence() NeilBrown
2019-05-30 0:41 ` [PATCH 8/9] pNFS: Allow multiple connections to the DS NeilBrown
2019-05-30 0:41 ` [PATCH 1/9] SUNRPC: Add basic load balancing to the transport switch NeilBrown
2019-05-30 0:41 ` [PATCH 7/9] NFSv4: Allow multiple connections to NFSv4.x servers NeilBrown
2019-05-30 0:41 ` [PATCH 6/9] NFS: Add a mount option to specify number of TCP connections to use NeilBrown
2019-05-30 17:05 ` [PATCH 0/9] Multiple network connections for a single NFS mount Tom Talpey
2019-05-30 17:20 ` Olga Kornievskaia
2019-05-30 17:41 ` Tom Talpey
2019-05-30 18:41 ` Olga Kornievskaia
2019-05-31 1:45 ` Tom Talpey
2019-05-30 22:38 ` NeilBrown
2019-05-31 1:48 ` Tom Talpey
2019-05-31 2:31 ` NeilBrown
2019-05-31 12:39 ` Tom Talpey
2019-05-30 23:53 ` Rick Macklem
2019-05-31 0:15 ` J. Bruce Fields
2019-05-31 1:01 ` NeilBrown
2019-05-31 2:20 ` Rick Macklem
2019-05-31 12:36 ` Tom Talpey
2019-05-31 13:33 ` Trond Myklebust
2019-05-30 17:56 ` Chuck Lever
2019-05-30 18:59 ` Olga Kornievskaia
2019-05-30 22:56 ` NeilBrown
2019-05-31 13:46 ` Chuck Lever
2019-05-31 15:38 ` J. Bruce Fields
2019-06-11 1:09 ` NeilBrown
2019-06-11 14:51 ` Chuck Lever
2019-06-11 15:05 ` Tom Talpey
2019-06-11 15:20 ` Trond Myklebust
2019-06-11 15:35 ` Chuck Lever
2019-06-11 16:41 ` Trond Myklebust
2019-06-11 17:32 ` Chuck Lever
2019-06-11 17:44 ` Trond Myklebust
2019-06-12 12:34 ` Steve Dickson
2019-06-12 12:47 ` Trond Myklebust
2019-06-12 13:10 ` Trond Myklebust
2019-06-11 15:34 ` Olga Kornievskaia
2019-06-11 17:46 ` Chuck Lever
2019-06-11 19:13 ` Olga Kornievskaia
2019-06-11 20:02 ` Tom Talpey
2019-06-11 20:09 ` Chuck Lever
2019-06-11 21:10 ` Olga Kornievskaia
2019-06-11 21:35 ` Tom Talpey
2019-06-11 22:55 ` NeilBrown
2019-06-12 12:55 ` Tom Talpey
2019-06-11 23:02 ` NeilBrown
2019-06-11 23:21 ` NeilBrown
2019-06-12 12:52 ` Tom Talpey
2019-06-11 23:42 ` NeilBrown
2019-06-12 12:39 ` Steve Dickson [this message]
2019-06-12 17:36 ` Chuck Lever
2019-06-12 23:03 ` NeilBrown
2019-06-13 16:13 ` Chuck Lever
2019-06-12 1:49 ` NeilBrown
2019-06-12 18:32 ` Chuck Lever
2019-06-12 23:37 ` NeilBrown
2019-06-13 16:27 ` Chuck Lever
2019-05-31 0:24 ` J. Bruce Fields
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=e4b6f790-c87c-5839-2de5-67ec561cda3d@RedHat.com \
--to=steved@redhat.com \
--cc=Anna.Schumaker@netapp.com \
--cc=aglo@umich.edu \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.com \
--cc=trondmy@hammerspace.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).