On Sat, Sep 10, 2016 at 10:40 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Sat, Sep 10, 2016 at 09:52:21AM +1000, Dave Chinner wrote: >> > vfs_copy_file_range() implementation because ovl_copy_up_data() >> > splices in small chunks allowing the user to kill the copying process. >> > This makes sense because the poor process only called open(), >> > so the app writer may not have been expecting a stall of copying >> > a large file... >> >> So call vfs_copy_file_range() iteratively, just like is being done >> right now for do_splice_direct() to limit latency on kill. > > I wish vfs_copy_file_range would do useful chinking itself. > I guess that is more changes then I set out to do here, but if there is consensus about this idea I don't mind drafting the patch. > But either way it might be a good idea to call vfs_clone_file_range > first, because that gives your a very efficient copy without the need > to copy anything if supported. Definitely. I'll do that. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
