bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 02/01/2023 23:18, Paul Eggert wrote:
On 2023-01-02 15:03, Pádraig Brady wrote:
On 20/11/2022 03:50, Paul Eggert wrote:
Although we inadvertently removed support for weird devices in 2009 by
commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to
care (because people use dd or whatever to deal with weird devices), I
think it'd be better to limit the fix to regular files. And while we're
at it we might as well resurrect support for weird devices.
Paul I'm happy with your patch for this.
I've rebased and tweaked the summary and NEWS slightly in the attached.
OK for me to apply?
Sure, that looks good, thanks.
I forgot about documenting the reinstated I/O block size multiple constraint,
which I'll do with the attached.
cheers,
Pádraig
From e01c06fb9c182151d4bbbe90873f79b5b2295245 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Mon, 2 Jan 2023 23:16:07 +
Subject: [PATCH] doc: copy: mention the reinstated I/O size constraints
* NEWS: Mention the change in behavior re block size multiples
to support unusual devices with this constraint.
* src/copy.c (copy_reg): Likewise.
---
NEWS | 4
src/copy.c | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 7a655974a..dce09e9ba 100644
--- a/NEWS
+++ b/NEWS
@@ -58,6 +58,10 @@ GNU coreutils NEWS-*- outline -*-
'cp --reflink=always A B' no longer leaves behind a newly created
empty file B merely because copy-on-write clones are not supported.
+ cp, mv, and install again read in multiples of the reported block size,
+ to support unusual devices that may have this constraint.
+ [behavior inadvertently changed in coreutils-7.2]
+
'ls -v' and 'sort -V' go back to sorting ".0" before ".A",
reverting to the behavior in coreutils-9.0 and earlier.
This behavior is now documented.
diff --git a/src/copy.c b/src/copy.c
index 1058b08ec..251769300 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1387,7 +1387,9 @@ copy_reg (char const *src_name, char const *dst_name,
if (! make_holes)
{
/* Compute the least common multiple of the input and output
- buffer sizes, adjusting for outlandish values. */
+ buffer sizes, adjusting for outlandish values.
+ Note we read in multiples of the reported block size
+ to support (unusual) devices that have this constraint. */
size_t blcm_max = MIN (SIZE_MAX, SSIZE_MAX);
size_t blcm = buffer_lcm (io_blksize (src_open_sb), buf_size,
blcm_max);
--
2.26.2
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 2023-01-02 15:03, Pádraig Brady wrote: On 20/11/2022 03:50, Paul Eggert wrote: Although we inadvertently removed support for weird devices in 2009 by commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to care (because people use dd or whatever to deal with weird devices), I think it'd be better to limit the fix to regular files. And while we're at it we might as well resurrect support for weird devices. Paul I'm happy with your patch for this. I've rebased and tweaked the summary and NEWS slightly in the attached. OK for me to apply? Sure, that looks good, thanks.
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 20/11/2022 03:50, Paul Eggert wrote:
Although we inadvertently removed support for weird devices in 2009 by
commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to
care (because people use dd or whatever to deal with weird devices), I
think it'd be better to limit the fix to regular files. And while we're
at it we might as well resurrect support for weird devices.
Paul I'm happy with your patch for this.
I've rebased and tweaked the summary and NEWS slightly in the attached.
OK for me to apply?
Preemptively marking this as done.
cheers,
PádraigFrom 573979e21af8f9ea7f83660e949902b3330ce25e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 19 Nov 2022 19:04:36 -0800
Subject: [PATCH] copy: fix possible over allocation for regular files
* bootstrap.conf (gnulib_modules): Add count-leading-zeros,
which was already an indirect dependency, since ioblksize.h
now uses it directly.
* src/ioblksize.h: Include count-leading-zeros.h.
(io_blksize): Treat impossible blocksizes as IO_BUFSIZE.
When growing a blocksize to IO_BUFSIZE, keep it a multiple of the
stated blocksize. Work around the ZFS performance bug.
* NEWS: Mention the bug fix.
Problem reported by Korn Andras at https://bugs.gnu.org/59382
---
NEWS| 5 +
bootstrap.conf | 1 +
src/ioblksize.h | 28 +++-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 0fbfe7b09..40eb66968 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,11 @@ GNU coreutils NEWS-*- outline -*-
which may have resulted in data corruption.
[bug introduced in coreutils-7.5 and enabled by default in coreutils-9.0]
+ cp, mv, and install avoid allocating too much memory, and possibly
+ triggering "memory exhausted" failures, on file systems like ZFS,
+ which can return varied file system I/O block size values for files.
+ [bug introduced in coreutils-6.0]
+
'mv --backup=simple f d/' no longer mistakenly backs up d/f to f~.
[bug introduced in coreutils-9.1]
diff --git a/bootstrap.conf b/bootstrap.conf
index 247734673..f04c90624 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -59,6 +59,7 @@ gnulib_modules="
config-h
configmake
copy-file-range
+ count-leading-zeros
crypto/md5
crypto/sha1
crypto/sha256
diff --git a/src/ioblksize.h b/src/ioblksize.h
index 7a56c1a51..80d7931ba 100644
--- a/src/ioblksize.h
+++ b/src/ioblksize.h
@@ -18,6 +18,7 @@
/* sys/stat.h and minmax.h will already have been included by system.h. */
#include "idx.h"
+#include "count-leading-zeros.h"
#include "stat-size.h"
@@ -75,8 +76,33 @@ enum { IO_BUFSIZE = 128 * 1024 };
static inline idx_t
io_blksize (struct stat sb)
{
+ /* Treat impossible blocksizes as if they were IO_BUFSIZE. */
+ idx_t blocksize = ST_BLKSIZE (sb) <= 0 ? IO_BUFSIZE : ST_BLKSIZE (sb);
+
+ /* Use a blocksize of at least IO_BUFSIZE bytes, keeping it a
+ multiple of the original blocksize. */
+ blocksize += (IO_BUFSIZE - 1) - (IO_BUFSIZE - 1) % blocksize;
+
+ /* For regular files we can ignore the blocksize if we think we know better.
+ ZFS sometimes understates the blocksize, because it thinks
+ apps stupidly allocate a block that large even for small files.
+ This misinformation can cause coreutils to use wrong-sized blocks.
+ Work around some of the performance bug by substituting the next
+ power of two when the reported blocksize is not a power of two. */
+ if (S_ISREG (sb.st_mode)
+ && blocksize & (blocksize - 1))
+{
+ int leading_zeros = count_leading_zeros_ll (blocksize);
+ if (IDX_MAX < ULLONG_MAX || leading_zeros)
+{
+ unsigned long long power = 1ull << (ULLONG_WIDTH - leading_zeros);
+ if (power <= IDX_MAX)
+blocksize = power;
+}
+}
+
/* Don’t go above the largest power of two that fits in idx_t and size_t,
as that is asking for trouble. */
return MIN (MIN (IDX_MAX, SIZE_MAX) / 2 + 1,
- MAX (IO_BUFSIZE, ST_BLKSIZE (sb)));
+ blocksize);
}
--
2.26.2
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 2022-11-19 22:43, Korn Andras wrote: the same file can contain records of different sizes. Reductio ad absurdum: the "optimal" blocksize for reading may in fact depend on the position within the file (and only apply to the next read). This sort of problem exists on traditional devices as well. A tape drive can have records of different sizes. For these devices, the best approach is to allocate a buffer of the maximum blocksize the drive supports. For the file you describe the situation is different, since ZFS will straddle small blocks during I/O. Although there's no single "best" I would guess that it'd typically be better to report the blocksize currently in use for creating new blocks (which would be a power of two for ZFS), as that will map better to how programs like cp deal with blocksizes. This may not be perfect but it'd be better than what ZFS does now, at least for the instances of 'cp' that are already out there.
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 20/11/2022 03:50, Paul Eggert wrote:
The block size for filesystems can also be quite large (currently, up
to 16M).
It seems ZFS tries to "help" apps by reporting misinformation (namely a
smaller block size than actually preferred) when the file is small. This
is unfortunate, since it messes up cp and similar programs that need to
juggle multiple block sizes. Plus, it messes up any program that assumes
st_blksize is constant for the life of a file descriptor, which "cp"
does assume elsewhere.
GNU cp doesn't need ZFS's "help", as it's already smart enough to not
over-allocate a buffer when the input file is small but its blocksize is
large. Instead, this "help" from ZFS causes GNU cp to over-allocate
because it naively trusts the blocksize ZFS that reports.
The proposed patch attached removes the use of buffer_lcm()
and just picks the largest st_blksize, which would be 4MiB in your case.
It also limits the max buffer size to 32MiB in the edge case
where st_blksize returns a larger value that this.
I suppose this could break cp if st_blksize is not a power of 2, and if
the file is not a regular file, and reads must be a multiple of the
block size. POSIX allows such things though I expect nowadays it'd be
limited to weird devices.
Although we inadvertently removed support for weird devices in 2009 by
commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to
care (because people use dd or whatever to deal with weird devices), I
think it'd be better to limit the fix to regular files. And while we're
at it we might as well resurrect support for weird devices.
I wouldn't worry about weird devices TBH, for the reasons you state,
but it doesn't cost too much to support so fair enough.
I would definitely add a comment to the code in this regard though
as I certainly wasn't aware of that issue when I added commit 55efc5f3.
+#include
No need for this, as static_assert works without in C23, and
Gnulib's assert-h module support this.
cool
+/* Set a max constraint to avoid excessive mem usage or type overflow. */
+enum { IO_BUFSIZE_MAX = 128 * IO_BUFSIZE };
+static_assert (IO_BUFSIZE_MAX <= MIN (IDX_MAX, SIZE_MAX) / 2 + 1);
I'm leery of putting in a maximum as low as 16 MiB. Although that's OK
now (it matches OpenZFS's current maximum), cp in the future will surely
deal with bigger block sizes. Instead, how about if we stick with GNU's
"no arbitrary limits" policy and work around the ZFS bug instead?
Well I wouldn't think of this as a functional limit,
more of a defensive programming technique with possible perf benefits.
Note as per the table in ioblksize.h, performance is seen to max out
at around 2^17 on most systems, and degrades on some systems beyond that.
So cp would be faster while being less memory efficient.
But yes if we're relying on these multiples for "weird devices" then fair
enough,
that would be a functional limit, so we need to consider such large buffers.
Also to state it explicitly, for regular files, your change to clamp to a power
of two
will effectively get buffer_lcm to pick the max of the two io_blksize() values.
I would change the commit summary from:
cp: work around ZFS misinformation
to:
copy: fix possible over allocation for regular files
because:
- This also applies to cross device mv etc.
- ZFS is giving more info TBH, just a bit naïvely
- I do see this is a coreutils bug (as well)
Here is a NEWS entry as well:
cp, mv, and install avoid allocating too much memory, and possibly
triggering "memory exhausted" failures, on file systems like ZFS,
which can return varied file system I/O block size values for files.
[bug introduced in coreutils-6.0]
thanks!
Pádraig
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On Sat, Nov 19, 2022 at 07:50:06PM -0800, Paul Eggert wrote: > > > The block size for filesystems can also be quite large (currently, > > > up to 16M). > > It seems ZFS tries to "help" apps by reporting misinformation (namely a > smaller block size than actually preferred) when the file is small. This is Just a nit: this isn't actually misinformation. ZFS uses variable "block" sizes (it calls these blocks "records"). There is a configurable per-filesystem maximum, which records of new writes will not exceed (but may not reach); but existing files may use larger record sizes than what is currently configured for the fs. The currently-configured recordsize of the filesystem and the recordsize a particular file was written with are not necessarily related. Depending on the write pattern and whether the recordsize of the fs was changed during the lifetime of the file, the same file can contain records of different sizes. Reductio ad absurdum: the "optimal" blocksize for reading may in fact depend on the position within the file (and only apply to the next read). If a file fits into a single record, then, IIUC, it is actually optimal to read it in a single operation; this is the case even if the currently configured recordsize is smaller than what the allowed maximum was when the file was written. If the file is highly fragmented and chunks of it are stored on different physical media (this can easily happen if the zfs pool was expanded with a new "vdev" during the lifetime of the file), it will in fact be fastest to issue reads for several chunks in parallel, with read speed possibly scaling almost linearly with the number of parallel requests. (Not that I'm proposing cp(1) should try to figure this out, presumably in a zfs-specific way, and actually do it.) Since the file may contain records of various sizes that bear no relation to the current per-fs recordsize setting, it's not immediately obvious (at least to me) what st_blocksize zfs should report that can't be construed as misinformation. If you have strong opinions on the matter, you may want to explain them in the pertinent OpenZFS issue: https://github.com/openzfs/zfs/issues/14195. András -- I was once thrown out of a mental hospital for depressing the other patients.
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
The block size for filesystems can also be quite large (currently, up
to 16M).
It seems ZFS tries to "help" apps by reporting misinformation (namely a
smaller block size than actually preferred) when the file is small. This
is unfortunate, since it messes up cp and similar programs that need to
juggle multiple block sizes. Plus, it messes up any program that assumes
st_blksize is constant for the life of a file descriptor, which "cp"
does assume elsewhere.
GNU cp doesn't need ZFS's "help", as it's already smart enough to not
over-allocate a buffer when the input file is small but its blocksize is
large. Instead, this "help" from ZFS causes GNU cp to over-allocate
because it naively trusts the blocksize ZFS that reports.
The proposed patch attached removes the use of buffer_lcm()
and just picks the largest st_blksize, which would be 4MiB in your case.
It also limits the max buffer size to 32MiB in the edge case
where st_blksize returns a larger value that this.
I suppose this could break cp if st_blksize is not a power of 2, and if
the file is not a regular file, and reads must be a multiple of the
block size. POSIX allows such things though I expect nowadays it'd be
limited to weird devices.
Although we inadvertently removed support for weird devices in 2009 by
commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to
care (because people use dd or whatever to deal with weird devices), I
think it'd be better to limit the fix to regular files. And while we're
at it we might as well resurrect support for weird devices.
+#include
No need for this, as static_assert works without in C23, and
Gnulib's assert-h module support this.
+/* Set a max constraint to avoid excessive mem usage or type overflow. */
+enum { IO_BUFSIZE_MAX = 128 * IO_BUFSIZE };
+static_assert (IO_BUFSIZE_MAX <= MIN (IDX_MAX, SIZE_MAX) / 2 + 1);
I'm leery of putting in a maximum as low as 16 MiB. Although that's OK
now (it matches OpenZFS's current maximum), cp in the future will surely
deal with bigger block sizes. Instead, how about if we stick with GNU's
"no arbitrary limits" policy and work around the ZFS bug instead?
Something like the attached patch, perhaps?From 551f3f55180669ab0bfd6c5d9e3e0f38cb035172 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 19 Nov 2022 19:04:36 -0800
Subject: [PATCH] cp: work around ZFS misinformation
Problem reported by Korn Andras (Bug#59382).
* bootstrap.conf (gnulib_modules): Add count-leading-zeros,
which was already an indirect dependency, since ioblksize.h
now uses it directly.
* src/ioblksize.h: Include count-leading-zeros.h.
(io_blksize): Treat impossible blocksizes as IO_BUFSIZE.
When growing a blocksize to IO_BUFSIZE, keep it a multiple of the
stated blocksize. Work around the ZFS performance bug.
---
NEWS| 3 +++
bootstrap.conf | 1 +
src/ioblksize.h | 28 +++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index b6b5201e7..9282352c8 100644
--- a/NEWS
+++ b/NEWS
@@ -13,6 +13,9 @@ GNU coreutils NEWS-*- outline -*-
'cp -rx / /mnt' no longer complains "cannot create directory /mnt/".
[bug introduced in coreutils-9.1]
+ cp, mv, and install no longer use overly large I/O buffers when ZFS
+ misinforms them about IO block sizes.
+
'mv --backup=simple f d/' no longer mistakenly backs up d/f to f~.
[bug introduced in coreutils-9.1]
diff --git a/bootstrap.conf b/bootstrap.conf
index 8e257a254..f8715068e 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -59,6 +59,7 @@ gnulib_modules="
config-h
configmake
copy-file-range
+ count-leading-zeros
crypto/md5
crypto/sha1
crypto/sha256
diff --git a/src/ioblksize.h b/src/ioblksize.h
index 8bd18ba05..aa367aa4e 100644
--- a/src/ioblksize.h
+++ b/src/ioblksize.h
@@ -18,6 +18,7 @@
/* sys/stat.h and minmax.h will already have been included by system.h. */
#include "idx.h"
+#include "count-leading-zeros.h"
#include "stat-size.h"
@@ -75,8 +76,33 @@ enum { IO_BUFSIZE = 128 * 1024 };
static inline idx_t
io_blksize (struct stat sb)
{
+ /* Treat impossible blocksizes as if they were IO_BUFSIZE. */
+ idx_t blocksize = ST_BLKSIZE (sb) <= 0 ? IO_BUFSIZE : ST_BLKSIZE (sb);
+
+ /* Use a blocksize of at least IO_BUFSIZE bytes, keeping it a
+ multiple of the original blocksize. */
+ blocksize += (IO_BUFSIZE - 1) - (IO_BUFSIZE - 1) % blocksize;
+
+ /* For regular files we can ignore the blocksize if we think we know better.
+ ZFS sometimes understates the blocksize, because it thinks
+ apps stupidly allocate a block that large even for small files.
+ This misinformation can cause coreutils to use wrong-sized blocks.
+ Work around some of the performance bug by substituting the next
+ power of two when the reported blocksize is not a power of two. */
+ if (S_ISREG (sb.st_mode)
+ && blocksize & (blocksize - 1))
+{
+ int
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
On 19/11/2022 08:14, Korn Andras wrote:
Hi,
on zfs, newfstatat() can return an st_blksize that is approximately equal to
the file size in bytes (if the file fit into a single zfs record).
The block size for filesystems can also be quite large (currently, up to 16M).
The code at https://github.com/coreutils/coreutils/blob/master/src/copy.c#L1343 will try
to compute the least common multiple of the input and output block sizes, then allocate a
buffer of that size using mmap(). With such unusual block sizes, the least common
multiple can be very large, causing the mmap() to return ENOMEM and cp to abort with
"memory exhausted".
Example:
openat(AT_FDCWD, "tmp", O_RDONLY|O_PATH|O_DIRECTORY) = 3
newfstatat(AT_FDCWD, "usr/src/zfs-2.1.6/configure", {st_dev=makedev(0, 0x30),
st_ino=29267, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2647552,
st_blocks=5177, st_size=2647046, st_atime=1668786119 /*
2022-11-18T16:41:59.760703544+0100 */, st_atime_nsec=760703544, st_mtime=1667705386 /*
2022-11-06T04:29:46+0100 */, st_mtime_nsec=0, st_ctime=1668785062 /*
2022-11-18T16:24:22.866737598+0100 */, st_ctime_nsec=866737598}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, "configure", {st_dev=makedev(0, 0x32), st_ino=3838,
st_mode=S_IFREG|0700, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4194304, st_blocks=1,
st_size=0, st_atime=1668788205 /* 2022-11-18T17:16:45.416328293+0100 */,
st_atime_nsec=416328293, st_mtime=1668788255 /* 2022-11-18T17:17:35.809758585+0100 */,
st_mtime_nsec=809758585, st_ctime=1668788255 /* 2022-11-18T17:17:35.809758585+0100 */,
st_ctime_nsec=809758585}, 0) = 0
openat(AT_FDCWD, "usr/src/zfs-2.1.6/configure", O_RDONLY|O_NOFOLLOW) =
4
newfstatat(4, "", {st_dev=makedev(0, 0x30),
st_ino=29267, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=2647552,
st_blocks=5177, st_size=2647046, st_atime=1668786119 /* 2022-11-18T16:41:59.760703544+0100 */,
st_atime_nsec=760703544, st_mtime=1667705386 /* 2022-11-06T04:29:46+0100 */, st_mtime_nsec=0,
st_ctime=1668785062 /* 2022-11-18T16:24:22.866737598+0100 */, st_ctime_nsec=866737598},
AT_EMPTY_PATH) = 0
openat(3, "configure", O_WRONLY|O_TRUNC) = 5
ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EXDEV (Invalid
cross-device link)
newfstatat(5, "", {st_dev=makedev(0, 0x32), st_ino=3838,
st_mode=S_IFREG|0700, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4194304, st_blocks=1,
st_size=0, st_atime=1668788205 /* 2022-11-18T17:16:45.416328293+0100 */,
st_atime_nsec=416328293, st_mtime=1668788266 /* 2022-11-18T17:17:46.326056957+0100 */,
st_mtime_nsec=326056957, st_ctime=1668788266 /* 2022-11-18T17:17:46.326056957+0100 */,
st_ctime_nsec=326056957}, AT_EMPTY_PATH) = 0
fadvise64(4, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
copy_file_range(4, NULL, 5,
NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link)
mmap(NULL, 21688754176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
brk(0x55a7fa4b) = 0x55a2ed8ab000
mmap(NULL, 21689794560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
write(2>, "cp: ", 4) = 4
write(2>, "memory exhausted", 16) = 16
write(2>, "\n", 1) = 1
lseek(0>, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0>)= 0
close(1>)= 0
close(2>)= 0
exit_group(1) = ?
I think cp(1) shouldn't insist on using the lcm if it's very large;
additionally, it should never try to allocate a buffer that is (much) larger
than the source file.
Perhaps you could also try to use successively smaller buffers if allocating a
large one fails?
Thank you for the detailed report.
This buffer_lcm code has been present for a long time,
but I agree in the presence of disparate st_blksize values
it can result in inappropriate buffer sizes.
In your case:
src st_blksize = 2647552 (0x286600) (st_size = 2647046)
dst st_blksize = 4194304 (0x40) (st_size = 0)
Which implies a lowest common multiple of 21688745984
Once the st_blksize is based on st_size we can get very large values like this.
In the zfs case it seems to set st_blksize to st_size rounded to next multiple
of 512.
The proposed patch attached removes the use of buffer_lcm()
and just picks
bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual
Hi,
on zfs, newfstatat() can return an st_blksize that is approximately equal to
the file size in bytes (if the file fit into a single zfs record).
The block size for filesystems can also be quite large (currently, up to 16M).
The code at https://github.com/coreutils/coreutils/blob/master/src/copy.c#L1343
will try to compute the least common multiple of the input and output block
sizes, then allocate a buffer of that size using mmap(). With such unusual
block sizes, the least common multiple can be very large, causing the mmap() to
return ENOMEM and cp to abort with "memory exhausted".
Example:
openat(AT_FDCWD, "tmp", O_RDONLY|O_PATH|O_DIRECTORY) = 3
newfstatat(AT_FDCWD, "usr/src/zfs-2.1.6/configure", {st_dev=makedev(0, 0x30),
st_ino=29267, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=2647552, st_blocks=5177, st_size=2647046, st_atime=1668786119 /*
2022-11-18T16:41:59.760703544+0100 */, st_atime_nsec=760703544,
st_mtime=1667705386 /* 2022-11-06T04:29:46+0100 */, st_mtime_nsec=0,
st_ctime=1668785062 /* 2022-11-18T16:24:22.866737598+0100 */,
st_ctime_nsec=866737598}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, "configure", {st_dev=makedev(0, 0x32), st_ino=3838,
st_mode=S_IFREG|0700, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4194304,
st_blocks=1, st_size=0, st_atime=1668788205 /*
2022-11-18T17:16:45.416328293+0100 */, st_atime_nsec=416328293,
st_mtime=1668788255 /* 2022-11-18T17:17:35.809758585+0100 */,
st_mtime_nsec=809758585, st_ctime=1668788255 /*
2022-11-18T17:17:35.809758585+0100 */, st_ctime_nsec=809758585}, 0) = 0
openat(AT_FDCWD, "usr/src/zfs-2.1.6/configure", O_RDONLY|O_NOFOLLOW) =
4
newfstatat(4, "", {st_dev=makedev(0, 0x30),
st_ino=29267, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=2647552, st_blocks=5177, st_size=2647046, st_atime=1668786119 /*
2022-11-18T16:41:59.760703544+0100 */, st_atime_nsec=760703544,
st_mtime=1667705386 /* 2022-11-06T04:29:46+0100 */, st_mtime_nsec=0,
st_ctime=1668785062 /* 2022-11-18T16:24:22.866737598+0100 */,
st_ctime_nsec=866737598}, AT_EMPTY_PATH) = 0
openat(3, "configure", O_WRONLY|O_TRUNC) = 5
ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EXDEV (Invalid
cross-device link)
newfstatat(5, "", {st_dev=makedev(0, 0x32), st_ino=3838,
st_mode=S_IFREG|0700, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4194304,
st_blocks=1, st_size=0, st_atime=1668788205 /*
2022-11-18T17:16:45.416328293+0100 */, st_atime_nsec=416328293,
st_mtime=1668788266 /* 2022-11-18T17:17:46.326056957+0100 */,
st_mtime_nsec=326056957, st_ctime=1668788266 /*
2022-11-18T17:17:46.326056957+0100 */, st_ctime_nsec=326056957}, AT_EMPTY_PATH)
= 0
fadvise64(4, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
copy_file_range(4, NULL, 5,
NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link)
mmap(NULL, 21688754176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
brk(0x55a7fa4b) = 0x55a2ed8ab000
mmap(NULL, 21689794560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
write(2>, "cp: ", 4) = 4
write(2>, "memory exhausted", 16) = 16
write(2>, "\n", 1) = 1
lseek(0>, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0>)= 0
close(1>)= 0
close(2>)= 0
exit_group(1) = ?
I think cp(1) shouldn't insist on using the lcm if it's very large;
additionally, it should never try to allocate a buffer that is (much) larger
than the source file.
Perhaps you could also try to use successively smaller buffers if allocating a
large one fails?
András
--
Write your complaints in this box: -> []
