From: Nikolay Borisov <nborisov@suse.com>
To: Hristo Venev <hristo@venev.name>, linux-btrfs@vger.kernel.org
Cc: amir73il@gmail.com
Subject: Re: btrfs_clone_files and bind mounts
Date: Mon, 26 Feb 2018 15:01:13 +0200 [thread overview]
Message-ID: <4b9de5cb-1366-a95c-118c-7b57042bf32e@suse.com> (raw)
In-Reply-To: <1519646493.12248.7.camel@venev.name>
[CCing Amir since he touched precisely the code responsible for this
semantics]
On 26.02.2018 14:01, Hristo Venev wrote:
> On Tue, 2018-02-20 at 18:41 +0200, Nikolay Borisov wrote:
>>
>> On 20.02.2018 17:50, Hristo Venev wrote:
>>> What is the problem with cloning files between different
>>> (vfs)mounts of
>>> the same filesystem?
>>>
>>
>> The "problem" is not really a problem, but rather a well-imposed
>> restriction:
>>
>> From http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html
>>
>> "Both files must reside within the same filesystem."
>>
>> And as a matter of fact this is enforced in the generic
>> vfs_clone_file_range. Of course if we were to do this across
>> filesystem
>> then we'd have all the problems associated with not being able to
>> ensure
>> atomicity of operations.
>
> My question was about doing this within the same filesystem. In my case
> (and I think it's relatively common), subvolumes of the same filesystem
> are mounted separately, and I can't think of a good reason why
> FICLONERANGE can't be made to work (it works if the subvolumes are
> accessed within the same mount point).
>
So Amir,
In 913b86e92e1f ("vfs: allow vfs_clone_file_range() across mount
points") you did relax the requirements of vfs_clone_file_range by
moving the mount point check into ioctl_file_clone. In btrfs we can have
a situation where multiple subvolumes, belonging to the same FS are at
different mountpoint I.e. :
mount /dev/vdc /media/scratch/
echo "test file" >> /media/scratch/foo
btrfs subvolume create /media/scratch/subvol1
btrfs subvolume list /media/scratch/
ID 257 gen 7 top level 5 path subvol1
mount -osubvolid=257 /dev/vdc /media/subvol-mount/
cp --reflink=always /media/scratch/foo /media/subvol-mount/foo-reflink
cp: failed to clone '/media/subvol-mount/foo-reflink' from
'/media/scratch/foo': Invalid cross-device link
Shouldn't reflinking be allowed in this case? ftrace shows that we are
failing "if (src_file.file->f_path.mnt != dst_file->f_path.mnt)" in
ioctl_file_clone
In your commit you state:
FICLONE/FICLONERANGE ioctls enforce that src and dest files are on
the same mount.
Whereas the man page says they should be on the same filesystem (not
necessarily on the same mount?)
next prev parent reply other threads:[~2018-02-26 13:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-20 15:50 btrfs_clone_files and bind mounts Hristo Venev
2018-02-20 16:41 ` Nikolay Borisov
2018-02-26 12:01 ` Hristo Venev
2018-02-26 13:01 ` Nikolay Borisov [this message]
2018-02-26 13:51 ` 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=4b9de5cb-1366-a95c-118c-7b57042bf32e@suse.com \
--to=nborisov@suse.com \
--cc=amir73il@gmail.com \
--cc=hristo@venev.name \
--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).