When I first started on this stuff I followed the lead of previous work and added a new syscall for the copy operation: https://lkml.org/lkml/2013/5/14/618 Towards the end of that thread Eric Wong asked why we didn't just extend splice. I immediately replied with some dumb dismissive answer. Once I sat down and looked at it, though, it does make a lot of sense. So good job, Eric. +10 Dummie points for me. Extending splice avoids all the noise of adding a new syscall and naturally falls back to buffered copying as that's what the direct splice path does for sendfile() today. So that's what this patch series demonstrates. It adds a flag that lets splice get at the same direct splicing that sendfile() does. We then add a file system file_operations method to accelerate the copy which has access to both files. Some things to talk about: - I really don't care about the naming here. If you do, holler. - We might want different flags for file-to-file splicing and acceleration - We might want flags to require or forbid acceleration - We might want to provide all these flags to sendfile, too Thoughts? Objections? Bryan, do you see any problems with wiring the NFS COPY RPC under this? Martin, are we any closer to getting blk_() calls to kick off XCOPY bios? OCFS2 friends, is it a managable amount of work to implement an ocfs2_splice_direct() that only modifies a region of the destination file? Finally, there's a slot in the plumbers schedule next week to talk about this stuff. Come say hi if you're interested. -z -- 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
