linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>,
	Dave Chinner <david@fromorbit.com>,
	linux-unionfs@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>,
	linux-xfs@vger.kernel.org,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH v2 0/4] ovl: efficient copy up by reflink
Date: Mon, 12 Sep 2016 18:06:39 +0300	[thread overview]
Message-ID: <1473692803-11964-1-git-send-email-amir73il@gmail.com> (raw)
In-Reply-To: <1473348594-31425-1-git-send-email-amir73il@gmail.com>

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 two pairs of patches:
- patches 1,2 utilize the clone_file_range() API
- patches 3,4 utilize the copy_file_range() API

The two pairs of patches are independent of each other.
They were each tested separately and both tested together.
All combinations passed the unionmount-testsuite (over tmpfs)
All combinations 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,
which I implemented in this series:
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
file systems that can do either clone_file_range() or 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 the copy_file_range() step is never needed.
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 nfs is not supported as upper layer for overlayfs
at the moment.

Please pick patches 1,2 for clear and immediate benefit to copy up
performance on filesystems with reflink support.

Please consider picking patches 3,4 additionally for future generations
and for code consolidation into vfs helpers.

Cheers,
Amir.

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 (4):
  vfs: allow vfs_clone_file_range() across mount points
  ovl: use vfs_clone_file_range() for copy up if possible
  vfs: allow vfs_copy_file_range() across file systems
  ovl: use vfs_copy_file_range() to copy up file data

 fs/ioctl.c             |  2 ++
 fs/overlayfs/copy_up.c | 19 +++++++++++++++----
 fs/read_write.c        | 23 ++++++++++++++++-------
 3 files changed, 33 insertions(+), 11 deletions(-)

-- 
2.7.4


  parent reply	other threads:[~2016-09-12 15:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-08 15:29 [PATCH] ovl: use copy_file_range for copy up if possible Amir Goldstein
2016-09-08 20:25 ` Dave Chinner
2016-09-09  7:31   ` Amir Goldstein
2016-09-09  7:54     ` Dave Chinner
2016-09-09  8:27       ` Amir Goldstein
2016-09-09 23:52         ` Dave Chinner
2016-09-10  7:40           ` Christoph Hellwig
2016-09-10 18:15             ` Amir Goldstein
2016-09-10 18:54           ` Amir Goldstein
2016-09-11 22:11             ` Dave Chinner
2016-09-12  6:52               ` Amir Goldstein
2016-09-12 15:37                 ` Amir Goldstein
2016-09-12 15:06 ` Amir Goldstein [this message]
2016-09-12 15:06   ` [PATCH v2 1/4] vfs: allow vfs_clone_file_range() across mount points Amir Goldstein
2016-09-12 15:06   ` [PATCH v2 2/4] ovl: use vfs_clone_file_range() for copy up if possible Amir Goldstein
2016-09-13  0:02     ` Dave Chinner
2016-09-13  6:47       ` Amir Goldstein
2016-09-12 15:06   ` [PATCH v2 3/4] vfs: allow vfs_copy_file_range() across file systems Amir Goldstein
2016-09-13  0:08     ` Dave Chinner
2016-09-13  7:01       ` Amir Goldstein
2016-09-12 15:06   ` [PATCH v2 4/4] ovl: use vfs_copy_file_range() to copy up file data Amir Goldstein
2016-09-13  0:11     ` Dave Chinner
2016-09-13  7:26       ` Amir Goldstein
2016-09-14 12:43         ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1473692803-11964-1-git-send-email-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).