Re: Same mountpoint restriction in FICLONE ioctls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 13, 2020 at 10:40 PM Keno Fischer <keno@xxxxxxxxxxxxxxxxxx> wrote:
>
> > You make it sound like the heuristic decision must be made
> > *after* trying to clone, but it can be made before and pass
> > flags to the kernel whether or to fallback to copy.
>
> True, though I simplified slightly. There's other things we try
> first if the clone fails, like creating a hardlink. If cloning fails,
> we also often only want to copy a part of the file (again
> heuristically, whether more than what the program asked
> for will be useful for debugging)

Fair enough.

>
> > copy_file_range(2) has an unused flags argument.
> > Adding support for flags like:
> > COPY_FILE_RANGE_BY_FS
> > COPY_FILE_RANGE_BY_KERNEL
>
> That would solve it of course, and I'd be happy with that
> solution, but it seems like we'd end up with just another
> spelling for the cloning ioctls then that have subtly different
> semantics.
>

Yeh. Another spelling is a common way to change behavior.
In fact, it is the only way if you want to avoid changing behavior
of existing application.

Generally speaking, syscall interface is an improvement over ioctl
interface. Flags like:
COPY_FILE_RANGE_REFLINK
COPY_FILE_RANGE_NO_XDEV
along with proper documentation, can help make the change of behavior
explicit. The flags mentioned above would describe the existing
FICLONERANGE semantics.

But the thing is that the above is not just a fancy maneuver for relaxing the
same mnt restriction of FICLONERANGE.
I believe that enhancing the semantics of copy_file_range(2) has benefits
beyond your use case.
copy tools could make use of nfs/cifs server side copy without falling back
to kernel copy.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux