diff options
| author | Christoph Hellwig <hch@lst.de> | 2015-12-03 12:59:50 +0100 |
|---|---|---|
| committer | Al Viro <viro@zeniv.linux.org.uk> | 2015-12-07 23:11:33 -0500 |
| commit | 04b38d601239b4d9be641b412cf4b7456a041c67 (patch) | |
| tree | 196b5fa72848de2a98e09af86099d99da70f2833 /fs/btrfs/file.c | |
| parent | acc15575e78e534c12549d8057a692f490a50f61 (diff) | |
| download | op-kernel-dev-04b38d601239b4d9be641b412cf4b7456a041c67.zip op-kernel-dev-04b38d601239b4d9be641b412cf4b7456a041c67.tar.gz | |
vfs: pull btrfs clone API to vfs layer
The btrfs clone ioctls are now adopted by other file systems, with NFS
and CIFS already having support for them, and XFS being under active
development. To avoid growth of various slightly incompatible
implementations, add one to the VFS. Note that clones are different from
file copies in several ways:
- they are atomic vs other writers
- they support whole file clones
- they support 64-bit legth clones
- they do not allow partial success (aka short writes)
- clones are expected to be a fast metadata operation
Because of that it would be rather cumbersome to try to piggyback them on
top of the recent clone_file_range infrastructure. The converse isn't
true and the clone_file_range system call could try clone file range as
a first attempt to copy, something that further patches will enable.
Based on earlier work from Peng Tao.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/btrfs/file.c')
| -rw-r--r-- | fs/btrfs/file.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index e67fe6a..232e300 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2925,6 +2925,7 @@ const struct file_operations btrfs_file_operations = { .compat_ioctl = btrfs_ioctl, #endif .copy_file_range = btrfs_copy_file_range, + .clone_file_range = btrfs_clone_file_range, }; void btrfs_auto_defrag_exit(void) |
