This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/19882] New: copy_file_range missing from syscall tapset
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 29 Mar 2016 21:03:55 +0000
- Subject: [Bug tapsets/19882] New: copy_file_range missing from syscall tapset
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=19882
Bug ID: 19882
Summary: copy_file_range missing from syscall tapset
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: tapsets
Assignee: systemtap at sourceware dot org
Reporter: dsmith at redhat dot com
Target Milestone: ---
he copy_file_range syscall was added in kernel 4.5 by the following kernel
commit:
====
commit 29732938a6289a15e907da234d6692a2ead71855
Author: Zach Brown <zab@redhat.com>
Date: Tue Nov 10 16:53:30 2015 -0500
vfs: add copy_file_range syscall and vfs helper
Add a copy_file_range() system call for offloading copies between
regular files.
This gives an interface to underlying layers of the storage stack which
can copy without reading and writing all the data. There are a few
candidates that should support copy offloading in the nearer term:
- btrfs shares extent references with its clone ioctl
- NFS has patches to add a COPY command which copies on the server
- SCSI has a family of XCOPY commands which copy in the device
This system call avoids the complexity of also accelerating the creation
of the destination file by operating on an existing destination file
descriptor, not a path.
Currently the high level vfs entry point limits copy offloading to files
on the same mount and super (and not in the same file). This can be
relaxed if we get implementations which can copy between file systems
safely.
====
Support for copy_file_range() should be added to the syscall tapset.
--
You are receiving this mail because:
You are the assignee for the bug.