On Thu, Mar 09, 2017 at 07:35:59AM -0800, hch@xxxxxxxxxxxxx wrote: > 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. I guess I'm just hung up on the EINVAL vs. short copy behavior. It seems more annoying and error-prone to be prepared for both, as opposed to trying clone and then explicitly falling back to copy if that doesn't work. Maybe it's not that big a deal. > 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. Yeah. There are also some other offset, length combinations that currently return -EINVAL, I wonder if any of those could be repurposed e.g. for a "keep copying to end of file" call. --b. -- 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
