public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Steve Dickson <steved@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/1] Enable inter server to server copies on a export
Date: Fri, 29 Oct 2021 12:40:58 -0400	[thread overview]
Message-ID: <20211029164058.GE19967@fieldses.org> (raw)
In-Reply-To: <3e928624-6a7a-8583-7ea4-4eef9c22488e@redhat.com>

On Fri, Oct 29, 2021 at 10:56:24AM -0400, Steve Dickson wrote:
> On 10/29/21 09:45, J. Bruce Fields wrote:
> >Really, first I think we should try to identify what the problem is that
> >we're trying to solve.
> I'm not trying to solve any problem... I'm just trying to enable a
> feature in a sane and safe way. By only have one module param it
> is on all the time on all copies... With an export opt, admins
> can pick and choose which exports use it. I'm thinking that
> is a bit less risky.

So, I'm not sure which risk you're thinking about.

If it's the risk of the client telling the destination server to copy
from a rogue server--I'm kind of regretting bringing that up.  If there
are bugs in that area, I'd rather they be fixed, than that we introduce
new configuration to work around bugs that may or may not exist.  They'd
need to be fixed anyway, for other reasons.  I think Dai has volunteered
to look through the code that handles replies to the small number of
operations concerned, and I think that's good enough due diligence.  And
I'm not getting the impression Trond is particularly worried about the
client code here either.

If the risk is performance--like I say, I'm not sure exactly what those
cases look like.

I've been thinking about it in terms of bandwidth, but maybe that's
wrong--the bigger problem may be when the source server is only
accessible to the client for some reason (like, you're copying from a
local server to a destination server that's outside a firewall).  Maybe
the destination server will end up waiting a long time trying to reach
the source.

But, again, I'm not sure an export option helps, because I don't see why
that problem would necessarily be per-destination-server-export.

Instead, we may just need to make sure the destination server is quick
to timeout, or has some mechanism to blacklist source servers so it's
not repeatedly timing out trying to copy from the same server.  I don't
know, I'm just thinking out loud.

> The option of setting the inter_copy_offload_enable is still
> there... if admins want to go that route.

Let's just stick with that for now, and leave it off by default until
we're sure it's mature enough.  Let's not introduce new configuration to
work around problems that we haven't really analyzed yet.

It's not as though turning on a module option is any more difficult than
setting an export option.

--b.

  reply	other threads:[~2021-10-29 16:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 14:48 [PATCH 0/1] Enable inter server to server copies on a export Steve Dickson
2021-10-28 14:48 ` [PATCH 1/1] nfsd4_copy: Adds the ability to do inter server to server on an export Steve Dickson
2021-10-29 13:45 ` [PATCH 0/1] Enable inter server to server copies on a export J. Bruce Fields
2021-10-29 14:26   ` J. Bruce Fields
2021-10-29 15:24     ` Steve Dickson
2021-10-29 14:56   ` Steve Dickson
2021-10-29 16:40     ` J. Bruce Fields [this message]
2021-10-29 17:30       ` Steve Dickson
2021-10-29 19:14         ` J. Bruce Fields
2021-11-01 15:30           ` Steve Dickson
2021-11-01 15:40             ` J. Bruce Fields
2021-11-01 16:55               ` Chuck Lever III
2021-11-01 18:24                 ` Steve Dickson
2021-11-01 18:39                 ` Bruce Fields
2021-11-01 18:44                   ` Chuck Lever III
2021-11-01 19:10                   ` Steve Dickson
2021-11-01 19:26                     ` Bruce Fields
2021-11-01 20:28                       ` Steve Dickson
2021-11-01 19:02               ` Steve Dickson
2021-11-01 19:22                 ` dai.ngo
2021-11-01 19:25                   ` J. Bruce Fields
2021-11-01 20:25                     ` Steve Dickson
  -- strict thread matches above, loose matches on Subject: below --
2021-10-28 14:59 Steve Dickson

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=20211029164058.GE19967@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.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