On Fri, Apr 27, 2018 at 7:11 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > On Fri, Apr 27, 2018 at 12:03 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: >> 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? > > I'm really not involved with customer or know of how exactly they will > benefit. I have some knowledge of some company that is interested in > using copy offload functionality in game development. I have no > details. It has been talked about a case scenario of copying VM > images. I don't know if VMware uses copy offload or not. > >> 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.) > > I'm not in favor of dropping asynchronous piece as I think it's an > important performance improvement. It's likely it won't be must of an > improvement due to an overhead of establishing clientid/session for > every "chuck" of the copy that will be sent synchronously. > >> 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.) > > Ok, runtime option, I'll work on it. Hi Bruce, I would like to come back to this code and hopefully make progress. I heard about the LSF discussion that there was interest in the copy offload and async code. If so where do we stand now and what are the next steps now? -- 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
