From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:55106 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750839AbcIMALu (ORCPT ); Mon, 12 Sep 2016 20:11:50 -0400 Date: Tue, 13 Sep 2016 10:11:47 +1000 From: Dave Chinner To: Amir Goldstein Cc: Miklos Szeredi , linux-unionfs@vger.kernel.org, Christoph Hellwig , linux-xfs@vger.kernel.org, "Darrick J . Wong" , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 4/4] ovl: use vfs_copy_file_range() to copy up file data Message-ID: <20160913001147.GO22388@dastard> References: <1473348594-31425-1-git-send-email-amir73il@gmail.com> <1473692803-11964-1-git-send-email-amir73il@gmail.com> <1473692803-11964-5-git-send-email-amir73il@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1473692803-11964-5-git-send-email-amir73il@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Sep 12, 2016 at 06:06:43PM +0300, Amir Goldstein wrote: > Use vfs_copy_file_range() helper instead of calling do_splice_direct() > when copying up file data. > When copying up within the same fs, which supports copy_file_range(), > fs implementation can be more efficient then do_splice_direct(). > vfs_copy_file_range() helper falls back to do_splice_direct() if > it cannot use the file system's copy_file_range() implementation. > > Tested correct behavior when lower and upper are on: > 1. same ext4 (copy) > 2. same xfs + reflink patches + mkfs.xfs (copy) > 3. same xfs + reflink patches + mkfs.xfs -m reflink=1 (clone) > 4. different xfs + reflink patches + mkfs.xfs -m reflink=1 (copy) > > For comparison, on my laptop, xfstest overlay/001 (copy up of large > sparse files) takes less than 1 second in the xfs reflink setup vs. > 25 seconds on the rest of the setups. This is now stale, right? the reflink is done from the vfs_clone_file_range() call added in an earlier patch, not this change.... > Signed-off-by: Amir Goldstein > --- > fs/overlayfs/copy_up.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c > index e432d7e..32ea54f 100644 > --- a/fs/overlayfs/copy_up.c > +++ b/fs/overlayfs/copy_up.c > @@ -159,15 +159,16 @@ static int ovl_copy_up_data(struct path *old, struct path *new, loff_t len) > break; > } > > - bytes = do_splice_direct(old_file, &old_pos, > - new_file, &new_pos, > - this_len, SPLICE_F_MOVE); > + bytes = vfs_copy_file_range(old_file, old_pos, > + new_file, new_pos, > + this_len, 0); > if (bytes <= 0) { > error = bytes; > break; > } > - WARN_ON(old_pos != new_pos); > > + old_pos += bytes; > + new_pos += bytes; > len -= bytes; > } Patch does not remove the /* FIXME: copy up sparse files efficiently */ comment. Efficient copying of sparse files is something vfs_copy_file_range() should do internally.... Cheers, Dave. -- Dave Chinner david@fromorbit.com