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
