From: "Benjamin Coddington" <bcodding@redhat.com>
To: "Trond Myklebust" <trondmy@gmail.com>
Cc: "Bruce Fields" <bfields@fieldses.org>,
"Chuck Lever" <chuck.lever@oracle.com>,
"Olga Kornievskaia" <aglo@umich.edu>,
"Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: unsharing tcp connections from different NFS mounts
Date: Wed, 07 Oct 2020 14:04:24 -0400 [thread overview]
Message-ID: <7755CA77-7ABB-438A-A6E1-C3A73A54B7B3@redhat.com> (raw)
In-Reply-To: <6d9aee613e9fb25509c9317910189ee37a2e4b43.camel@hammerspace.com>
On 7 Oct 2020, at 12:44, Trond Myklebust wrote:
> I did see Igor's claim that there is a QoS issue (which afaics would
> also affect NFSv3), but why do I care about QoS as a per-mountpoint
> feature?
Because it's hard to do QoS without being able to classify the traffic on
the network somehow. The separate connection makes it a lot easier. I see
how that's - not our problem -, though.
The regular admin might find it surprising to tell their system to
connect to a specific IP address at mount time, and it instead sends the
mount's traffic elsewhere.
Are you happy with the state of nconnect, or is there room for something
more dynamic?
Ben
next prev parent reply other threads:[~2020-10-07 18:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 15:13 unsharing tcp connections from different NFS mounts J. Bruce Fields
2020-10-06 15:20 ` Chuck Lever
2020-10-06 15:22 ` Bruce Fields
2020-10-06 17:07 ` Tom Talpey
2020-10-06 19:30 ` Bruce Fields
[not found] ` <CAGrwUG5_KeRVR8chcA8=3FSeii2+4c8FbuE=CSGAtYVYqV4kLg@mail.gmail.com>
2020-10-07 14:08 ` Tom Talpey
2020-10-06 19:36 ` Benjamin Coddington
2020-10-06 21:46 ` Olga Kornievskaia
2020-10-07 0:18 ` J. Bruce Fields
2020-10-07 11:27 ` Benjamin Coddington
2020-10-07 12:55 ` Benjamin Coddington
2020-10-07 13:45 ` Chuck Lever
2020-10-07 14:05 ` Bruce Fields
2020-10-07 14:15 ` Chuck Lever
2020-10-07 16:05 ` Bruce Fields
2020-10-07 16:44 ` Trond Myklebust
2020-10-07 17:15 ` Bruce Fields
2020-10-07 17:29 ` Trond Myklebust
2020-10-07 18:05 ` bfields
2020-10-07 19:11 ` Trond Myklebust
2020-10-07 20:29 ` bfields
2020-10-07 18:04 ` Benjamin Coddington [this message]
2020-10-07 18:19 ` Trond Myklebust
2020-10-07 16:50 ` Trond Myklebust
2021-01-19 22:22 ` bfields
2021-01-19 23:09 ` Trond Myklebust
2021-01-20 15:07 ` bfields
2021-05-03 20:09 ` bfields
2021-05-04 2:08 ` NeilBrown
2021-05-04 13:27 ` Tom Talpey
2021-05-04 14:27 ` Trond Myklebust
2021-05-04 16:51 ` bfields
2021-05-04 21:32 ` Daire Byrne
2021-05-04 21:48 ` Trond Myklebust
2021-05-05 12:53 ` Daire Byrne
2021-01-20 15:58 ` Chuck Lever
2020-10-07 13:56 ` Patrick Goetz
2020-10-07 16:28 ` Igor Ostrovsky
2020-10-07 16:30 ` Benjamin Coddington
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=7755CA77-7ABB-438A-A6E1-C3A73A54B7B3@redhat.com \
--to=bcodding@redhat.com \
--cc=aglo@umich.edu \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@gmail.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 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.