linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Joshi <joshiiitr@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: cross-fs copy support
Date: Mon, 1 Oct 2018 22:48:15 +0800	[thread overview]
Message-ID: <2a92fff4-d005-835a-3bd7-a328b008857f@gmx.com> (raw)
In-Reply-To: <CA+1E3rLXPwzfO3ro49ZVg7RfpYon5YDB6Y_zqu60ivpgn4wenw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1519 bytes --]



On 2018/10/1 下午10:32, Joshi wrote:
> I was wondering about the cross-fs copy through copy_file_range.

The term "cross-fs" looks pretty confusing.

If you mean "cross-subvolume", then it should work without problem in btrfs.

If you mean reflink across two different file systems (not matter the
same fs type or not).
Then it's impossible to work.

Reflink (clone_file_range) works by inserting data pointers into the
filesystem other than really copying the data.
Thus if the source is outside of the fs, it's really impossible to work,
as the source pointer/data is completely out of control of the dest fs.

> It seems current implement has below check, that disables such copy.
> 
> 1577         /* this could be relaxed once a method supports cross-fs copies */
> 1578         if (inode_in->i_sb != inode_out->i_sb)
> 1579                 return -EXDEV;
> 
> May I know what are the thoughts behind disabling cross-fs copy?
> Code has the comment "once a method supports", but that leaves me
> wondering exactly what 'method' is expected, and from whom.
> 
> I disabled the check, and copy across volumes seemed to work fine. At
> least for a single file (1G size), with no data mismatch, and faster
> speed than regular copy.

Please provide the steps or script about how you did the reflink, in
case I misunderstand your "cross-fs" definition.

And just in case you're really doing cross filesystem reflink, please
also run "btrfs check" on both fs.

Thanks,
Qu



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-10-01 21:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-01 14:32 Joshi
2018-10-01 14:48 ` Qu Wenruo [this message]
2018-10-01 15:15   ` Joshi
2018-10-01 15:49   ` Eric Sandeen
2018-10-01 19:51     ` Andreas Dilger
2018-10-02  8:15       ` David Sterba
2018-10-02 15:19         ` Darrick J. Wong
2018-10-02 18:28       ` J. Bruce Fields

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=2a92fff4-d005-835a-3bd7-a328b008857f@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=joshiiitr@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --subject='Re: cross-fs copy support' \
    /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

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).