On Fri, Sep 23, 2016 at 11:38 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > This is the 4rd revision of implementing overlayfs > copy up by reflink. > > Btrfs has file reflink support and XFS is about to gain > file reflink support soon. It is very useful to use reflink > to implement copy up of regular file data when possible. > > For example, on my laptop, xfstest overlay/001 (copy up of 4G > sparse files) takes less than 1 second with copy up by reflink > vs. 25 seconds with regular copy up. > > This series includes 3 patches: > - patches 1,2 are re-factoring patches to allow using the > vfs_clone_file_range() helper from file system code. Christoph, Dave, Can you please ack the 2 vfs_clone_file_range() changes? Thanks, Amir. > - patch 3 utilizes the helper for overlay copy up > > These changes passed the unionmount-testsuite (over tmpfs) > They passed the overlay/??? xfstests over the following underlying fs: > 1. ext4 (copy up) > 2. xfs + reflink patches + mkfs.xfs (copy up) > 3. xfs + reflink patches + mkfs.xfs -m reflink=1 (reflink up) > > Dave Chinner suggested the following implementation for copy up: > 1. try to clone_file_range() entire length > 2. fallback to trying copy_file_range() in small chunks > 3. fallback to do_splice_direct() in small chunks > > This is a good general implementation to cover the future use cases of > filesystems that can do either clone_file_range() or copy_file_range() > and for filesystems that may fail clone_file_range() and succeed > to copy_file_range(). > > However, currently, the only in-tree file systems that support > clone/copy_file_range are btrfs, xfs (soon), cifs and nfs. > btrfs and xfs use the same implementation for clone and copy range, > so copy_file_range() in small chunks is only useful in extreme > ENOSPC cases. > cifs supports only clone_file_range() so copy_file_range() step is moot. > nfs does have a different implementation for clone_file_range() and > copy_file_range(), but neither nfs nor cifs are supported as lower layer > for overlayfs. > > For this posting, I decided to leave out the copy_file_range() patches > until a reliable use case to test them presents itself. > > Miklos, > > Please pick these patches to your tree for clear and immediate benefit to > copy up performance on filesystems with reflink support. > > Thanks, > Amir. > > V4: > - Fix recursive mnt_want_write() > - Leave out the vfs_copy_file_range() patches > > V3: > - Address style comments from Dave Chinner > > V2: > - Re-factor vfs helpers so they can be called from copy up > - Single call to vfs_clone_file_range() and fallback to > vfs_copy_file_range() loop > > V1: > - Replace iteravite call to copy_file_range() with > a single call to clone_file_range() > > V0: > - Call clone_file_range() and fallback to do_splice_direct() > > > Amir Goldstein (3): > vfs: allow vfs_clone_file_range() across mount points > vfs: call vfs_clone_file_range() under mnt_want_write() > ovl: use vfs_clone_file_range() for copy up if possible > > fs/ioctl.c | 11 +++++++++++ > fs/overlayfs/copy_up.c | 8 ++++++++ > fs/read_write.c | 13 ++++++------- > 3 files changed, 25 insertions(+), 7 deletions(-) > > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
