bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

Pádraig Brady <[email protected]>
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.