bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2023-01-02 Thread Pádraig Brady
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2023-01-02 Thread Paul Eggert
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2023-01-02 Thread Pádraig Brady
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-20 Thread Paul Eggert
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-20 Thread Pádraig Brady
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-20 Thread Korn Andras
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-19 Thread Paul Eggert
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-19 Thread Pádraig Brady
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

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

2022-11-19 Thread Korn Andras
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