On 09/08/2015 11:21 AM, Pádraig Brady wrote: > 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. Metadata copying could be added later if somebody really wants it. > >> 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? The idea is that filesystems get to choose how to handle copies in the default case. BTRFS could do a reflink, but NFS could do a server side copy instead. I can change the default behavior to only do a data copy (unless the reflink flag is specified) instead, if that is desirable. What does everybody think? Anna > > thanks, > Pádraig > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
