Repository navigation
core/passthrough: support the COPY_FILE_RANGE request - #262
Merged
Merged
Conversation
The ABI already defines Opcode::CopyFileRange (47) with CopyFileRangeIn, and the io_uring session already knows the request length, but the server never dispatched the opcode: a copy_file_range(2) issued on the mount was always answered with ENOSYS, so the kernel disabled the op and fell back to its generic splice-based copy loop. Wire the request up following the LSEEK precedent: a copy_file_range() method on FileSystem and AsyncFileSystem with a default ENOSYS, the Arc<FS> delegation, a Linux-gated server handler replying WriteOut, and dispatch arms in the sync and async servers. PassthroughFs forwards it to the copy_file_range(2) syscall with the request's explicit offsets, so the backing files' own positions are neither read nor advanced and no locking against lseek() is needed; the requested length is capped at u32::MAX because the WriteOut reply reports the copied length as a u32. File systems that keep the default still get the documented ENOSYS-to-fallback contract, and VFS and OverlayFs are left on it, as they are for lseek. Ported from PR cloud-hypervisor#220 ("Add support for copy_file_range"). Co-authored-by: EJ Campbell <ejc3@users.noreply.github.com> Signed-off-by: Jiang Liu <gerry@linux.alibaba.com>
jiangliu
requested review from
bergwolf,
eryugey,
imeoer and
liubogithub
as code owners
October 10, 2026 02:33
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ABI already defines Opcode::CopyFileRange (47) with CopyFileRangeIn, and the io_uring session already knows the request length, but the server never dispatched the opcode: a copy_file_range(2) issued on the mount was always answered with ENOSYS, so the kernel disabled the op and fell back to its generic splice-based copy loop.
Wire the request up following the LSEEK precedent: a copy_file_range() method on FileSystem and AsyncFileSystem with a default ENOSYS, the Arc delegation, a Linux-gated server handler replying WriteOut, and dispatch arms in the sync and async servers. PassthroughFs forwards it to the copy_file_range(2) syscall with the request's explicit offsets, so the backing files' own positions are neither read nor advanced and no locking against lseek() is needed; the requested length is capped at u32::MAX because the WriteOut reply reports the copied length as a u32. File systems that keep the default still get the documented ENOSYS-to-fallback contract, and VFS and OverlayFs are left on it, as they are for lseek.
Ported from PR #220 ("Add support for copy_file_range").