> On Mar 9, 2017, at 11:17 AM, hch@xxxxxxxxxxxxx wrote: > > On Thu, Mar 09, 2017 at 11:16:01AM -0500, bfields@xxxxxxxxxxxx wrote: >> 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. > > We can do short copies^H^H^H^H^Hclones for clone just as easily, > at least for local filesystems (NFS would require some tweaks due to the > protocol). I’m confused by the wording of “we can do … easily” . Is “can” = in the future? Currently, testing copy_file_range() on a btfs with argument of offset+len beyond the end of the file fail with EINVAL. Is NFS tweaking = revert the “MUST” in the spec for the check? -- 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
