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.
