[fullquote removed, please get your email etiquette right or I'll stop responding] > For fs that support both copy and clone, I am not convinced that it up to > VFS to take that decision for the application. We had that discussion many times. Yes, the system can decide it, as the application does not see the difference. > If application 'chose' copy over clone maybe it had a reason. Yes, because it's lazy and simply doesn't give a f**k how the data is copied. Clone provides much stronger guarantees, but if you don't need them you'll just use call that will always work. > I suggest to move this to 'clone fallback' after copy_file_range and before > do_splice_direct. That won't do the right thing for the NFS case. > 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 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
