copy_file_range op?

[SUPERCILEX]

There's splice but no copy_file_range. It'd be great to have.

[axboe]

copy_file_range() just uses splice underneath the covers for the generic implementation anyway, can't you just use that directly from io_uring as well?

If not, it could certainly be wired up. But the majority of the work would be enabling nonblocking issue of it, otherwise you'd end up in the same situation potentially as your unlink issue.

[SUPERCILEX]

Splice only works if one of the FDs is a pipe according the docs, so that won't work.

[axboe]

Right, so you'd splice to a pipe, splice from a pipe. Not ideal, but it'd work.

[SUPERCILEX]

Won't that introduce an unnecessary copy?

[vlovich]

Yeah, I think a real copy_file_range implementation is required. Many filesystems these days support reflinks which copy_file_range would take advantage of while splice would generate a copy.

       copy_file_range() gives filesystems an opportunity to implement
       "copy acceleration" techniques, such as the use of reflinks
       (i.e., two or more inodes that share pointers to the same copy-
       on-write disk blocks) or server-side-copy (in the case of NFS).

So if I'm copying on the same XFS/BTFS/EXT4 filesystem (& recently ZFS too I believe), copy_file_range would copy a few inodes max regardless of the file size (+not actually consume that space) whereas splice would duplicate the entire file.

copy_file_range is only a splice under the hood when copying across filesystems. Within a single filesystem there's an accelerated path available.