--- Begin Message ---
|
Subject: |
cp fails for files > 2 GB if copy offload is unsupported |
|
Date: |
Fri, 02 Jun 2023 16:44:57 +0100 |
|
User-agent: |
mu4e 1.10.3; emacs 29.0.91 |
Hello,
Forwarding a downstream report of a behaviour change between
coreutils-9.1 and coreutils-9.3 from https://bugs.gentoo.org/907474.
The reporter bisected it to 093a8b4bfaba60005f14493ce7ef11ed665a0176
("copy: fix --reflink=auto to fallback in more cases", see bug#62404)
and gave strace output showing:
```
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 2147479552
copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = -1 EINVAL
(Invalid argument)
```
"""
When I try to copy a large file (> 2 GB) like so:
cp --debug file_a file_b
output looks like this:
'file_a' -> 'file_b'
cp: error copying 'file_a' to 'file_b': Invalid argument
copy offload: unsupported, reflink: unsupported, sparse detection: no
Afterwards file_b has a size of 2147479552 bytes (= 2G - 4K).
On another system (with newer kernel version) it looks like this:
cp --debug file_a file_b
'file_a' -> 'file_b'
copy offload: yes, reflink: unsupported, sparse detection: no
"""
Let me know if you need further information, although there's
some more on the downstream Gentoo bug I linked.
Apparently this is only happening w/ the 4.19.x kernels.
Thanks!
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported |
|
Date: |
Wed, 7 Jun 2023 12:13:28 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 |
On 2023-06-06 03:02, Sam James wrote:
Thanks Paul. Do you know if there's any other cases of this in gnulib?
There's no other use of linux/version.h in Gnulib. However, this doesn't
mean there are no other instances of the problem, as it's common to
assume that you'll run on a host no older than the build host. Every use
of Autoconf macros like AC_RUN_IFELSE assume this sort of thing, and I
would not be surprised if there are other examples of this more-general
problem when some builders (unwisely) build apps intended to run on
platforms older than the build platform. (For what it's worth, I count
331 uses of AC_RUN_IFELSE in Gnulib; it'd be a pain to audit them all.)
It's OK to build glibc for Linux kernels somewhat older than the build
kernel, since glibc explicitly exports that. But it's not OK to build
other packages that way, since they don't support it. You'll get away
with it in many cases, but when it doesn't work then the problem is on
the builder, not on the packages being built.
(or whether, by chance, if you know off the top of your head if any
other gnulib consumers definitely use copy_file_range?)
Other coreutils programs like 'install' use copy_file_range.
Emacs uses it. I just now installed the following patch into
bleeding-edge Emacs to work around the problem, by updating to current
Gnulib. This workaround should appear in Emacs 30, whenever that happens
(not for a year or two I'd think, as Emacs 29 isn't out yet).
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a902156068ab071f93cc9bbd34cd320919b74064
PS. I'm boldly marking the coreutils bug as fixed.
--- End Message ---