Re: [PATCH 0/1] Enable inter server to server copies on a export

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Oct 29, 2021 at 09:45:34AM -0400, bfields wrote:
> On Thu, Oct 28, 2021 at 10:48:50AM -0400, Steve Dickson wrote:
> > This kernel patch and an upcoming nfs-utils patch
> > adds a new export option 's2sc' which will allow
> > inter server to server copies.
> 
> They're already allowed by a module option.  Why is an export option
> better?  And why should it be set on the destination server and not the
> source server?
> 
> Really, first I think we should try to identify what the problem is that
> we're trying to solve.

I guess we're thinking: we expect server-to-server copy to be a win in
some cases, but not others.

What would those cases look like?

Say you've got a client "C" and two servers, "S" and "T", and C is
copying a file from S to T.

I'd expect bandwidth of the traditional read-write-loop copy to be the
minimum of the network bandwidth between S and C, and the network
bandwidth between C and T.  Are there common cases were the S-to-T
bandwidth would be significantly less than both of those?

My guess would've been that that's relatively unusual.  So as a first
pass, just turning on COPY unconditionally doesn't seem so bad.

I know you're thinking about in cases where S and T are connected by a
high-performance network not necessarily available to C.

In that case, we know we want to use server-to-server copy for copies
between S and T.  But is it necessarily a problem to also use it for
copies between some other server and T?  Also, does knowing the export
containing the destination file on T really tell you whether or not the
copy will be coming from S and not from some other server?

I'd think the bigger issue in that case is figuring out how to configure
S so that it returns the right IP address in the cnr_source_server field
of the COPY_NOTIFY reply.  Currently we return address that the client
sent the COPY_NOTIFY, and I don't know if that's correct for that case.

--b.