> On Mar 9, 2017, at 11:16 AM, bfields@xxxxxxxxxxxx wrote: > > 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. I’m confused at which layer are we calling clone() and if we get EINVAL we call copy()? In VFS? Or are we talking about the case where there are two different system calls clone_file_range() and copy_file_range() that are provided to the “cp” and it calls one and then falls back onto another? > >> 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
