From a44202e98b638024c45e50ad404c7069c7835c04 Mon Sep 17 00:00:00 2001 From: Zbigniew Jędrzejewski-Szmek Date: Tue, 15 Mar 2016 19:26:34 -0400 Subject: basic/copy: use copy_file_range() For btrfs, c_f_r() is like BTRFS_IOC_CLONE which we already used, but also works when max_bytes is set. We do call copy_bytes in coredump code with max_bytes set, and for large files, so we might see some benefit from using c_f_r() on btrfs. For other filesystems, c_f_r() falls back to do_splice_direct(), the same as sendfile, which we already call, so there shouldn't be much difference. Tested with test-copy and systemd-coredump on Linux 4.3 (w/o c_f_r) and 4.5 (w/ c_f_r). --- TODO | 2 -- 1 file changed, 2 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 08b74083d3..b2840ba4ab 100644 --- a/TODO +++ b/TODO @@ -49,8 +49,6 @@ Features: * cache sd_event_now() result from before the first iteration... -* support for the new copy_file_range() syscall - * add systemctl stop --job-mode=triggering that follows TRIGGERED_BY deps and adds them to the same transaction * Maybe add a way how users can "pin" units into memory, so that they are not subject to automatic GC? -- cgit v1.2.3-54-g00ecf