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.
