On Tue, Nov 29, 2016 at 10:55 AM, Christoph Hellwig <hch@xxxxxx> wrote: > [fullquote removed, please get your email etiquette right or I'll stop > responding] > Sorry. I though the practice was to keep original patch in tact for review. > >> A hypothetical case why copy_range implementation would be preferred >> by an application that runs over specific hypothetical fs - copy_file_range >> can be more easily implemented as a killable copy loop, returning the length >> that was copy before interrupted by a signal. > > Clone is a fast metadata operation and is finished before you even > had a chance to kill it. To be fair, Clone is a fast metadata operation on xfs/btrfs/ocfs2. I don't think we can know for sure how a future file systems will choose to implement clone, nor can we tell for sure how any version of remote Windows CIFS server will implement it. The only thing we do know for sure is that the API difference between clone_range and copy_range must be respected. But in any case, if you say all this was already discussed in the past, I personally have no strong feeling against forcing clone. Thanks for clarifying my questions, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
