[please trim your replies instead of this giant unreadable garbage, thanks!] On Thu, Mar 09, 2017 at 10:29:48AM -0500, bfields@xxxxxxxxxxxx wrote: > So I don't understand why it needed to be added to copy_file_range(). > The copy and clone semantics are different enough that I think callers > want to know which they're getting. Because if a file systems implements clone is literally is always better than doing a copy loop, so using it is an absolute non-brainer. > Don't we want it to have more or less the same behavior as a read-write > loop? People are probably running backup programs that depend on just > simple copies, and maybe the results are good enough for their purposes, > or maybe they're actually corrupting parts of their backups and don't > know, but we can't suddenly start aborting their backups with errors and > tell users it's for their own good. So copy_file_range() callers will > need to handle EINVAL on changing files somehow. They do, and the system call has been in the tree for almost a year and a half, so we can't simply change it. Fortunately we do have a flags argument that can be used to implement your preferred semantics if you care deeply enough about them.
