diff options
| author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2016-03-16 00:26:34 +0100 |
|---|---|---|
| committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2016-03-17 18:02:18 +0100 |
| commit | a44202e98b638024c45e50ad404c7069c7835c04 (patch) | |
| tree | 1b82ca988d199923f37315d2f935626abdb2a8a3 /TODO | |
| parent | basic/missing: add copy_file_range (diff) | |
| download | systemd-a44202e98b638024c45e50ad404c7069c7835c04.tar.xz systemd-a44202e98b638024c45e50ad404c7069c7835c04.zip | |
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).
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 2 |
1 files changed, 0 insertions, 2 deletions
@@ -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? |