A question about this hunk:
@@ -619,9 +615,9 @@ lseek_copy (int src_fd, int dest_fd, char **abuf, size_t
buf_size,
is conservative and may miss some holes. */
off_t n_read;
if ( ! sparse_copy (src_fd, dest_fd, abuf, buf_size,
- true, allow_reflink, src_name, dst_name,
+ allow_reflink, src_name, dst_name,
ext_len,
- sparse_mode == SPARSE_ALWAYS ? hole_size : nullptr,
+ sparse_mode != SPARSE_NEVER ? hole_size : nullptr,
&n_read))
return false;
The comment above that is:
/* 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.
I.e. it undoes https://github.com/coreutils/coreutils/commit/879d2180d
BTW commit 26bf557 also changed this a couple of weeks ago
without updating the comment, so the comment relates to sparse_mode !=
SPARSE_ALWAYS.
If we do decide to change behavior here it should documented in NEWS,
but I don't think this is the right compromise.
If we can't handle all cases optimally, I'd be inclined to err on being
as performant as possible by default, and only try harder to look for holes
with --sparse=always. squashfs is giving the wrong info here after all, right?
cheers,
Padraig.
