All of lore.kernel.org
 help / color / mirror / Atom feed
From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "chuck.lever@oracle.com" <chuck.lever@oracle.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"aglo@umich.edu" <aglo@umich.edu>,
	"bcodding@redhat.com" <bcodding@redhat.com>,
	Jacob Shivers <jshivers@redhat.com>,
	Frank Sorenson <fsorenso@redhat.com>
Subject: Re: unsharing tcp connections from different NFS mounts
Date: Tue, 19 Jan 2021 17:22:29 -0500	[thread overview]
Message-ID: <20210119222229.GA29488@fieldses.org> (raw)
In-Reply-To: <e06c31e4211cefda52091c7710d871f44dc9160e.camel@hammerspace.com>

On Wed, Oct 07, 2020 at 04:50:26PM +0000, Trond Myklebust wrote:
> As far as I can tell, this thread started with a complaint that
> performance suffers when we don't allow setups that hack the client by
> pretending that a multi-homed server is actually multiple different
> servers.
> 
> AFAICS Tom Talpey's question is the relevant one. Why is there a
> performance regression being seen by these setups when they share the
> same connection? Is it really the connection, or is it the fact that
> they all share the same fixed-slot session?
> 
> 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?

Sorry for being slow to get back to this.

Some more details:

Say an NFS server exports /data1 and /data2.

A client mounts both.  Process 'large' starts creating 10G+ files in
/data1, queuing up a lot of nfs WRITE rpc_tasks.

Process 'small' creates a lot of small files in /data2, which requires a
lot of synchronous rpc_tasks, each of which wait in line with the large
WRITE tasks.

The 'small' process makes painfully slow progress.

The customer previously made things work for them by mounting two
different server IP addresses, so the "small" and "large" processes
effectively end up with their own queues.

Frank Sorenson has a test showing the difference; see

	https://bugzilla.redhat.com/show_bug.cgi?id=1703850#c42
	https://bugzilla.redhat.com/show_bug.cgi?id=1703850#c43

In that test, the "small" process creates files at a rate thousands of
times slower when the "large" process is also running.

Any suggestions?

--b.

  reply	other threads:[~2021-01-19 22:23 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
2020-10-07 18:19                       ` Trond Myklebust
2020-10-07 16:50                   ` Trond Myklebust
2021-01-19 22:22                     ` bfields [this message]
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=20210119222229.GA29488@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=aglo@umich.edu \
    --cc=bcodding@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=fsorenso@redhat.com \
    --cc=jshivers@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --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 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.