On Tue, Apr 24, 2018 at 04:29:14PM -0400, Olga Kornievskaia wrote: > On Wed, Apr 18, 2018 at 3:08 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Tue, Apr 17, 2018 at 11:19:25AM -0400, Olga Kornievskaia wrote: > >> Yes I agree. Let’s please decide if this will go in (with whatever code improvements are required) or let’s drop it. > > > > Well, my vote is very clearly to drop it. > > Bruce, when will you make a decision about this? Is there something > more that needs to happen before it can be decided if the "async" > patches are moving forward (and then "inter" patches). I'm OK with the patches. It could help to have some more information about actual customer use cases: who specifically is asking for this, and what about their situation makes them believe they'll benefit? But to me it seems obvious that server-to-server copy will be faster in some cases as long there's not some screwup preventing it from using the server-to-server bandwidth (and your numbers don't show any). So I'm not terribly worried about this. If we wanted to simplify I think we could ditch the asynchronous protocol and still make server-to-server copy work as a series of synchronous calls. (Or maybe that would make getting good performance the complicated part.) The only security issue I'm worried about is the fact that you can make it try to copy from any arbitrary IP address. I'd be satisfied if we document the issue and make server-to-server-copy support require a runtime switch that defaults to off. (And with that in place I don't see a need to also provide a build option.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
