<div dir="ltr"><div><div>1.<br>sendfile() and splice uses temporary buffer in terms of pipe.<br><br>do_splice_direct(in.file, &amp;pos, out.file, &amp;out_pos, count, fl) -&gt; <br>splice_direct_to_actor(struct file *in, struct splice_desc *sd, splice_direct_actor *actor)<br><br><a href="http://lxr.free-electrons.com/source/fs/splice.c#L602">http://lxr.free-electrons.com/source/fs/splice.c#L602</a><br><br>default_file_splice_read() allocates a page, read data for file1 from disk to the page, then write the page to a pipe.<br><br>default_file_splice_write() reads from the pipe, writes to a page, then write page to the file2.<br><br>So this is not a zero-copy in kernel. This can be a zero-copy from userspace point of view as we are not doing copy to userspace. but still a copy is involved a we are doing write to temporary buffer, for example: pipe.<br><br><br>2.<br>if copy_file_range() is defined for a filesystem operation then splice is not used. otherwise<br>copy_file_range() uses splice method of temporary buffer in terms of a pipe.<br><br><a href="http://lxr.free-electrons.com/source/fs/read_write.c#L1412">http://lxr.free-electrons.com/source/fs/read_write.c#L1412</a><br><br>ret = file_out-&gt;f_op-&gt;copy_file_range(file_in, pos_in, file_out,<br>1413                                                       pos_out, len, flags);<br>1414         if (ret == -EOPNOTSUPP)<br>1415                 ret = do_splice_direct(file_in, &amp;pos_in, file_out, &amp;pos_out,<br>1416                                 len &gt; MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);<br>1417<br><br>copy_file_range() does the following things that is much better method than splice. <br><br>COPY_FR_COPY means to copy the data normally, accelerating the work at the filesystem level if possible.<br><br>    COPY_FR_REFLINK asks for the destination file to refer to the existing copy of the data without actually<br>copying it. Some filesystems (Btrfs, for example) are able to share references to file blocks in this way.<br><br>    COPY_FR_DEDUP is like COPY_FR_REFLINK, but it only succeeds if the destination range already contains  the same data as the source. The end result is files that look the same as before, but which are now sharing the data on-disk. It is thus a way of removing blocks of duplicated data within the filesystem.<br><br>The COPY_FR_COPY operation will, in the absence of filesystem-level acceleration, copy the data directly through the kernel page cache; it is essentially a splice() operation. Copying through the page cache in this way is clearly more efficient than doing the copy in user space, since it avoids the need to copy the data out of the kernel and back in again. If possible, of course, copying with COPY_FR_REFLINK will be the most efficient approach. <br><br><br>copy_file_range() does not do the copy. It does a clone of a range of blocks of a file.<br><br><br>2921 const struct file_operations btrfs_file_operations = {<br>2922        ...<br>2935         .copy_file_range = btrfs_copy_file_range,<br>2936         .clone_file_range = btrfs_clone_file_range,<br>2937         .dedupe_file_range = btrfs_dedupe_file_range,<br>2938 };<br><br>3902 ssize_t btrfs_copy_file_range(struct file *file_in, loff_t pos_in,<br>3903                               struct file *file_out, loff_t pos_out,<br>3904                               size_t len, unsigned int flags)<br>3905 {<br>3906         ssize_t ret;<br>3907<br>3908         ret = btrfs_clone_files(file_out, file_in, pos_in, len, pos_out);<br>3909         if (ret == 0)<br>3910                 ret = len;<br>3911         return ret;<br>3912 }<br><br></div>Regards<br></div>Manoj Nayak<br></div>