Crates.io | xcp |
lib.rs | xcp |
version | 0.21.2 |
source | src |
created_at | 2018-10-28 06:13:40.949968 |
updated_at | 2024-06-29 00:34:52.093186 |
description | xcp is a (partial) clone of the Unix `cp` command, with more user-friendly feedback and some performance optimisations. See the README for features and limitations. |
homepage | https://github.com/tarka/xcp |
repository | https://github.com/tarka/xcp |
max_upload_size | |
id | 93058 |
size | 156,412 |
xcp
is a (partial) clone of the Unix cp
command. It is not intended as a
full replacement, but as a companion utility with some more user-friendly
feedback and some optimisations that make sense under certain tasks (see
below).
Warning: xcp
is currently beta-level software and almost certainly contains
bugs and unexpected or inconsistent behaviour. It probably shouldn't be used for
anything critical yet.
Please note that there are some known issues with copying files from virtual
filesystems (e.g. /proc
, /sys
). See this LWN
article for an overview of some of the
complexities of dealing with kernel-generated files. This is a common problem
with file utilities which rely on random access; for example rsync
has the
same issue.
NOTE: xcp
requires Rust 1.70 or higher.
xcp
can be installed directly from crates.io
with:
cargo install xcp
xcp
is available on the Arch Linux User Repository. If you use an AUR helper, you can execute a command such as this:
yay -S xcp
xcp
is available on NetBSD from the official repositories. To install it, simply run:
pkgin install xcp
--no-progress
.copy_file_range
call to copy files. This is the most
efficient method of file-copying under Linux; in particular it is
filesystem-aware, and can massively speed-up copies on network mounts by
performing the copy operations server-side. However, unlike copy_file_range
sparse files are detected and handled appropriately..gitignore
files to limit the copied directories.cp
's
--sparse=always
flag.lseek
.cp
--no-perms
./proc
and /sys
files.--reflink=never
option may silently perform a reflink operation
regardless. This is due to the use of
copy_file_range
which has no such override and may perform its own optimisations.cp
'simple' backups are not supported, only numbered.cp
options are not available but may be added in the future.Benchmarks are mostly meaningless, but the following are results from a laptop
with an NVMe disk and in single-user mode. The target copy directory is a git
checkout of the Firefox codebase, having been recently gc'd (i.e. a single 4.1GB
pack file). fstrim -va
and echo 3 | sudo tee /proc/sys/vm/drop_caches
are
run before each test run to minimise SSD allocation performance interference.
Note: xcp
is optimised for 'modern' systems with lots of RAM and solid-state
disks. In particular it is likely to perform worse on spinning disks unless they
are in highly parallel arrays.
cp
: ~6.2sxcp
: ~4.2scp
: ~1.85sxcp
: ~1.7scp
: ~48sxcp
: ~56scp
: ~6.9sxcp
: ~7.4sxcp
uses copy_file_range
, which is filesystem aware. On NFSv4 this will result
in the copy occurring server-side rather than transferring across the network. For
large files this can be a significant win:
cp
: 6m18sxcp
: 0m37s