Feature #13867: Copy offloading in IO.copy_stream

• Status: Closed
• Assignee: Glass_saga (Masaki Matsushita)
• Target version: 2.5

[Glass_saga (Masaki Matsushita)]

In linux 4.5, the copy offloading feature with copy_file_range(2) was introduced.
This patch enables IO.copy_stream to use it.
If "offload" keyword argument is specified, IO.copy_stream will try copy offloading.

IO.copy_stream("src", "dst", offload: true)

If copy offloading is not available on the system, "offload" option will be ignored.

When "src" and "dst" are not in the same filesystem, copy_file_range(2) must fail with EXDEV.
In this case, IO.copy_steram will fallback to another method (sendfile(2) or read/write) silently.

It depends on the filesystem what offloading techniques will be used.
Copy offloading is optional in IO.copy_stream because some techniques may change the current behavior.

[normalperson (Eric Wong)]

[e-mail] wrote:

In linux 4.5, the copy offloading feature with copy_file_range(2) was introduced.
This patch enables IO.copy_stream to use it.

Cool.

If "offload" keyword argument is specified, IO.copy_stream will try copy offloading.

Is a new keyword arg necessary? Since this is Linux-only, and
we already do fstat tests on both FDs in the sendfile checking:

We can try using copy_file_range if both src and dst are both
regular files with identical .st_dev, and fall back to using
sendfile on ENOSYS.

Thanks.

[shyouhei (Shyouhei Urabe)]

We took a look at this issue at yesterday's developer meeting and agreed with Eric here; it can be automatically applied whenever possible. Seems there are no practical reasons to disable this feature.

[Glass_saga (Masaki Matsushita)]

• File patch2.diff patch2.diff added
• Status changed from Open to Assigned
• Assignee set to Glass_saga (Masaki Matsushita)

This patch makes IO.copy_stream use copy_file_range(2) without keyword arguments.

[Glass_saga (Masaki Matsushita)]

• Status changed from Assigned to Closed

commited in r60284.

[normalperson (Eric Wong)]

[e-mail] wrote:

commited in r60284.

https://bugs.ruby-lang.org/issues/13867#change-67462

While working on r60490 to workaround O_APPEND; I noticed
there's an unnecessary fstat call for dst_stat. I don't see how
it is necessary to fstat dst_fd since copy_file_range will fail
anyways on invalid FDs.