Hi Paul,
I tested with the code currently in the master branch in coreutils -
top of tree respec is 4bfcf62f74b38d762ee06ceef582c326023635a9.
This current code still fixes my testcase thanks !
For full reference, it contains the 3 relevant patches:
commit 6c668dc133af7d374790c1da666a701e21682a35
Author: Pádraig Brady <p...@draigbrady.com>
Date: Sat Aug 23 18:53:17 2025 +0100
tests: cp: ensure copy offload is not disabled for sparse files
Related to commits v9.1-109-g879d2180d and v9.7-248-g306de6c26
* tests/cp/sparse-perf.sh: This edge case was missed a couple of times,
so add a test to ensure we attempt copy offload.
commit 39f22fe687ea0c226e3fb35e86cd5ea329180b80
Author: Paul Eggert <egg...@cs.ucla.edu>
Date: Fri Aug 22 17:34:04 2025 -0700
cp: improve hole handling on squashfs
Better fix for problem reported by Jeremy Allison
<https://bugs.gnu.org/79267>.
* src/copy.c (struct scan_inference): New type, replacing
union scan_inference. All uses changed. This is so
infer_scantype can report the first hole's offset when known.
(lseek_copy): 5th arg is now struct scan_inference const *,
not just off_t. All uses changed.
(infer_scantype): If SEEK_SET+SEEK_HOLE do not find a hole,
fall back on ZERO_SCANTYPE.
commit 306de6c2619e2a9339ade9a88d55c4940942d516
Author: Paul Eggert <egg...@cs.ucla.edu>
Date: Fri Aug 22 10:37:50 2025 -0700
cp: go back to copy_file_range optimization
This reverts part of the previous change.
* src/copy.c (lseek_copy): When calling sparse_copy, do not
ask it to scan for zeros unless --sparse=always, so that it
can use copy_file_range which can be far more efficient.
Cheers,
Jeremy.
On Fri, Aug 22, 2025 at 5:48 PM Paul Eggert <egg...@cs.ucla.edu> wrote:
>
> On 8/22/25 07:04, Pádraig Brady wrote:
> > /* Copy this extent, looking for further opportunities to not
> > bother to write zeros if --sparse=always, since SEEK_HOLE
> > is conservative and may miss some holes. */
> >
> > So the comment needs to be tweaked, but a more general issue
> > is that it disables copy offloading (copy_file_range) for sparse files.
>
> Ouch, I didn't see that. That's a real loss. I installed the first
> attached patch to revert that part of my recent change.
>
> I assume the part of the change that always punches holes is OK. I
> couldn't see why one would not want to punch a hole if one has already
> taken the trouble to find and create the hole.
>
> > BTW commit 26bf557 also changed this a couple of weeks ago
> > without updating the comment, so the comment relates to sparse_mode !=
> > SPARSE_ALWAYS.
>
> Not quite following but I hope the comment is OK now with the first
> patch installed.
>
> > squashfs is giving the wrong info here after all,
> > right?
>
> Yes, that's the actual space-performance bug here. I installed the
> second attached patch to try to work around it.
>
> Jeremy, can you please try these two further patches? Thanks.
