From: Nikolay Borisov <nborisov@suse.com>
To: fdmanana@kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] Btrfs: use generic_remap_file_range_prep() for cloning and deduplication
Date: Mon, 10 Dec 2018 10:48:22 +0200 [thread overview]
Message-ID: <d4bce2da-7803-8e5c-90a2-1ef8fe6be05f@suse.com> (raw)
In-Reply-To: <20181207152538.19269-1-fdmanana@kernel.org>
On 7.12.18 г. 17:25 ч., fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> Since cloning and deduplication are no longer Btrfs specific operations, we
> now have generic code to handle parameter validation, compare file ranges
> used for deduplication, clear capabilities when cloning, etc. This change
> makes Btrfs use it, eliminating a lot of code in Btrfs and also fixing a
> few bugs, such as:
>
> 1) When cloning, the destination file's capabilities were not dropped
> (the fstest generic/513 tests this);
>
> 2) We were not checking if the destination file is immutable;
>
> 3) Not checking if either the source or destination files are swap
> files (swap file support is coming soon for Btrfs);
>
> 4) System limits were not checked (resource limits and O_LARGEFILE).
>
> Note that the generic helper generic_remap_file_range_prep() does start
> and waits for writeback by calling filemap_write_and_wait_range(), however
> that is not enough for Btrfs for two reasons:
>
> 1) With compression, we need to start writeback twice in order to get the
> pages marked for writeback and ordered extents created;
>
> 2) filemap_write_and_wait_range() (and all its other variants) only waits
> for the IO to complete, but we need to wait for the ordered extents to
> finish, so that when we do the actual reflinking operations the file
> extent items are in the fs tree. This is also important due to the fact
> that the generic helper, for the deduplication case, compares the
> contents of the pages in the requested range, which might require
> reading extents from disk in the very unlikely case that pages get
> invalidated after writeback finishes (so the file extent items must be
> up to date in the fs tree).
>
> Since these reasons are specific to Btrfs we have to do it in the Btrfs
> code before calling generic_remap_file_range_prep(). This also results in
> a more simple way of dealing with existing delalloc in the source/target
> ranges, specially for the deduplication case where we used to lock all the
> pages first and then if we found any dealloc for the range, or ordered
> extent, we would unlock the pages trigger writeback and wait for ordered
> extents to complete, then lock all the pages again and check if
> deduplication can be done. So now we get a simpler approach: lock the
> inodes, then trigger writeback and then wait for ordered extents to
> complete.
>
> So make btrfs use generic_remap_file_range_prep() (XFS and OCFS2 use it)
> to eliminate duplicated code, fix a few bugs and benefit from future bug
> fixes done there - for example the recent clone and dedupe bugs involving
> reflinking a partial EOF block got a counterpart fix in the generic helpe,
> since it affected all filesystems supporting these operations, so we no
> longer need special checks in Btrfs for them.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Two minor suggestions but other LGTM so:
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
> ---
>
> V2: Removed check that verifies if either of the inodes is a directory,
> as it is done by generic_remap_file_range_prep(). Oddly in btrfs was being
> done only for cloning but not for dedupe.
>
> fs/btrfs/ioctl.c | 612 ++++++++++++-------------------------------------------
> 1 file changed, 129 insertions(+), 483 deletions(-)
>
<snip>
> @@ -4213,11 +3854,9 @@ static noinline int btrfs_clone_files(struct file *file, struct file *file_src,
> struct inode *inode = file_inode(file);
> struct inode *src = file_inode(file_src);
> struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
nit: This variable can be removed and btrfs_sb...
> - struct btrfs_root *root = BTRFS_I(inode)->root;
> int ret;
> u64 len = olen;
> u64 bs = fs_info->sb->s_blocksize;
can be used directly here, since we only care about the blocksize, saves
sizeof(void *) worth of bytes on the stack.
> - int same_inode = src == inode;
>
> /*
> * TODO:
> @@ -4230,101 +3869,32 @@ static noinline int btrfs_clone_files(struct file *file, struct file *file_src,
> * be either compressed or non-compressed.
> */
>
> - if (btrfs_root_readonly(root))
> - return -EROFS;
> -
> - if (file_src->f_path.mnt != file->f_path.mnt ||
> - src->i_sb != inode->i_sb)
> - return -EXDEV;
> -
> - if (S_ISDIR(src->i_mode) || S_ISDIR(inode->i_mode))
> - return -EISDIR;
> -
> - if (!same_inode) {
> - btrfs_double_inode_lock(src, inode);
> - } else {
> - inode_lock(src);
> - }
> -
> /* don't make the dst file partly checksummed */
> if ((BTRFS_I(src)->flags & BTRFS_INODE_NODATASUM) !=
> - (BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM)) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> + (BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM))
> + return -EINVAL;
This common check between btrfs_extent_same and btrfs_clone_files can be
factored out to btrfs_remap_file_range_prep or btrfs_remap_file_range
>
> - /* determine range to clone */
> - ret = -EINVAL;
> - if (off + len > src->i_size || off + len < off)
> - goto out_unlock;
> - if (len == 0)
> - olen = len = src->i_size - off;
<snip>
> }
>
>
next prev parent reply other threads:[~2018-12-10 8:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 13:24 [PATCH] Btrfs: use generic_remap_file_range_prep() for cloning and deduplication fdmanana
2018-12-07 15:25 ` [PATCH v2] " fdmanana
2018-12-10 8:48 ` Nikolay Borisov [this message]
2018-12-12 18:51 ` David Sterba
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=d4bce2da-7803-8e5c-90a2-1ef8fe6be05f@suse.com \
--to=nborisov@suse.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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).