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.
