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

On 11/3/25 15:47, Paul Eggert wrote:
> On 2025-08-23 12:03, Paul Eggert wrote:
>> On 2025-08-23 11:46, Phillip Lougher wrote:
>>> As far as Squashfs is concerned SEEK_HOLE/SEEK_DATA is easy to 
>>> implement.  So I'll think about adding it as a build option.
>>
>> Thanks, that'll be helpful.
>>
>>> But this isn't going to fix it for any other case.
>>
>> Right, and bleeding-edge coreutils already has a (slowish) workaround 
>> for Squashfs as-is, as well as for other file systems that don't 
>> expose extents to user code. If I get around to it I will install 
>> similar workarounds in other user code I help maintain.
>
> Phillip, as it turns out "slowish" was an understatement, as the 
> performance regression was so bad for OpenZFS that we plan to stop 
> using the workaround in the next release of GNU Coreutils. This change 
> will resurrect coreutils bug #79267, i.e., coreutils copying from 
> squashfs filesystems will no longer look for holes, and will create 
> unnecessary explicit zeros in the output. For details, please see:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79267#54
> https://github.com/coreutils/coreutils/issues/122
>
> Implementing SEEK_HOLE and SEEK_DATA for squashfs would be a better 
> way to fix the squashfs+coreutils performance bug. It's OK if squashfs 
> uses 128 KiB or 1 MiB block sizes for this, as Coreutils will work 
> fine either way.

I implemented it in September, and it is in the upstream kernel 
(currently at 2.18-rc4).

See

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dec91e7ab10ec465d59144aabe69c01723ddd1c4

https://www.phoronix.com/news/Linux-6.18-Non-MM-PR

Phillip