On Thu, Mar 09, 2017 at 12:28:03PM -0500, Olga Kornievskaia wrote: > > > 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? Checking https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41 ... looks like the CLONE result doesn't even have a length. Most users are probably cloning the whole file, so I guess it only matters in the case the file's changing (so that the size returned from stat might not be correct by the time you do the clone). Allowing short copies would be one way to handle that--I think it'd work then to just always request a clone to the maximum length. Alternatively if the linux interface just had a way to say "clone to end of file", that'd solve most of the problem and be a nice fit for the existing NFS protocol (which special-cases length 0 to mean "to end of file"). Maybe we could special-case the maximum size_t to mean that. (What is that, 2^63-1?.) --b.
