[beta] always disable copy_file_range to avoid EOVERFLOW errors

[the8472]

A bigger hammer as alternative to #79007

Pro: will certainly fix the issue
Cons: will disable copy_file_range for everyone

Resolves#78979

[rust-highfive]

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️Warning⚠️

• Pull requests are usually filed against the master branch for this repo, but this one is against beta. Please double check that you specified the right target!

[Mark-Simulacrum]

r? @Mark-Simulacrum

This is going to just be a (possible) performance hit, right? Do we have numbers on it (perhaps from a past PR)? I am wondering basically if the fix here is worth the performance loss; maybe we should gate the disable on e.g. mips or something like that.

cc @pietroalbini this or #79007 will likely want to land into 1.48

[the8472]

This is going to just be a (possible) performance hit, right? Do we have numbers on it (perhaps from a past PR)? I am wondering basically if the fix here is worth the performance loss; maybe we should gate the disable on e.g. mips or something like that.

It's not just performance. copy_file_range can also save disk space if you're on btrfs or xfs by creating reflink copies, That might also be relevant for anything running in certain container setups.

As for the performance numbers:

# userspace copy
test io::tests::bench_file_to_file_copy ... bench: 21,002 ns/iter (+/- 750) = 6240 MB/s [ext4]
test io::tests::bench_file_to_file_copy ... bench: 35,704 ns/iter (+/- 1,108) = 3671 MB/s [btrfs]
# copy_file_range
test io::tests::bench_file_to_file_copy ... bench: 14,745 ns/iter (+/- 519) = 8889 MB/s [ext4]
test io::tests::bench_file_to_file_copy ... bench: 6,128 ns/iter (+/- 227) = 21389 MB/s [btrfs]

[Mark-Simulacrum]

Ok, the performance impact is not too big and this is the most minimal patch, so I think it's the right thing to backport to 1.48 and 1.49 (once that branches).

@bors r+ rollup=never p=1

[bors]

📌 Commit d19e2de has been approved by Mark-Simulacrum

[mati865]

Ok, the performance impact is not too big and this is the most minimal patch

I find this statement a bit confusing when looking at the results.
With BTRFS (and very likely XFS) it's quite a performance difference and delaying reflink support is a pity.

That said it's not a regression/performance degradation but an optimisation delayed by few more weeks (with proper reason) so the decision is understandable.

[Mark-Simulacrum]

Yes, and ultimately (AFAIK) use of such file systems is somewhat unusual, though not entirely unexpected. I also somewhat expect that the specialization here is likely not used by cases where it is absolutely critical to get this behavior - those likely want to call the relevant APIs directly. Once we get more assurance that this all works and roll it out for a while we may provide more guarantees here

[bors]

⌛ Testing commit d19e2de with merge a238a370d9a199d57826b528681c572fa0929f03...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

@bors retry spurious apple lldb error

[bors]

⌛ Testing commit d19e2de with merge 61bc95a...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 61bc95a to beta...

[Mark-Simulacrum]

beta-nominating & accepting this for backport (really forward port) to 1.49, which has just branched.

[the8472]

Do you need a separate PR for that?

[Mark-Simulacrum]

No, I will pick it up as a part of regular beta backports, likely sometime in the next week or two.