On 23/08/2025 17:46, Paul Eggert wrote:
On 2025-08-22 19:11, Phillip Lougher wrote:
any Squashfs SEEK_HOLE/SEEK_DATA implementation will not
behave like other Linux filesystems, because it won't report sparseness
at the 4K granularity that most people or programs will expect it to.

Coreutils doesn't expect 4 KiB granularity for LSEEK_DATA+LSEEK_HOLE, and I don't know of any programs that do expect it. I fail to see why squashfs should penalize the performance of core programs like 'cp' merely because some (which?) programs are poorly written.

Yeah let's take the attitude everyone writes well written programs, and if they don't it's their fault when they unexpectedly break in production.   In reality a lot of code in embedded Linux systems is dreadful, written by inexperienced programmers.

Anyway, my email was pointing out that the SEEK_HOLE behaviour being complained about is the default Linux VFS behaviour.  So this isn't about Squashfs.

Go into the Linux kernel fs directory and run the following script.

% yes=""; no=""; for i in *; do if [ -d $i ]; then l=$(find $i -name "*.[ch]" | xargs grep SEEK_HOLE | wc -l); if [ $l -ne 0 ]; then yes+=" "$i ; else no+=" "$i; fi; fi; done; yc=$(echo $yes | wc -w); nc=$(echo $no | wc -w); echo -e "\nSEEK_HOLE"=$yc $yes; echo -e "\nNo SEEK_HOLE"=$nc $no

SEEK_HOLE=18 bcachefs btrfs cachefiles ceph erofs ext4 f2fs fuse gfs2 hpfs iomap nfs nfsd ocfs2 orangefs overlayfs smb xfs

No SEEK_HOLE=60 9p adfs affs afs autofs befs bfs coda configfs cramfs crypto debugfs devpts dlm ecryptfs efivarfs efs exfat exportfs ext2 fat freevxfs hfs hfsplus hostfs hugetlbfs isofs jbd2 jffs2 jfs kernfs lockd minix netfs nfs_common nilfs2 nls notify ntfs3 omfs openpromfs proc pstore qnx4 qnx6 quota ramfs resctrl romfs squashfs sysfs tests tracefs ubifs udf ufs unicode vboxsf verity zonefs

This picks up some false positives, but there are much more filesystems which don't support SEEK_HOLE than those that do.  If you think this is a problem with the Linux kernel then by all means raise it on the linux kernel mailing list.

Cheers

Phillip





Reply via email to