On 04/09/15 21:16, Anna Schumaker wrote: > Copy system calls came up during Plumbers a couple of weeks ago, because > several filesystems (including NFS and XFS) are currently working on copy > acceleration implementations. We haven't heard from Zach Brown in a while, > so I volunteered to push his patches upstream so individual filesystems > don't need to keep writing their own ioctls. Just mentioning that this is just pertaining to the data, not the metadata. Providing metadata copying facilities would be _very_ useful, as most file system specific details relate to the metadata, and having VFS operations for that would avoid the plethora of details in each userspace tool, and theoretically support translations between disparate metadata. > The first three patches are a simple reposting of Zach's patches from several > months ago, with one minor error code fix. The remaining patches add in a > fallback mechanism when filesystems don't provide a copy function. This is > especially useful when doing a server-side copy on NFS (using the new COPY > operation in NFS v4.2). This fallback can be disabled by passing the flag > COPY_REFLINK to the system call. I see copy_file_range() is a reflink() on BTRFS? That's a bit surprising, as it avoids the copy completely. cp(1) for example considered doing a BTRFS clone by default, but didn't due to expectations that users actually wanted the data duplicated on disk for resilience reasons, and for performance reasons so that write latencies were restricted to the copy operation, rather than being introduced at usage time as the dest file is CoW'd. If reflink() is a possibility for copy_file_range() then could it be done optionally with a flag? thanks, Pádraig -- 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
