https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205
Bug ID: 256205
Summary: lseek() with SEEK_HOLE some times wrongly reports
holes on ZFS
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
While experimenting with star on an arm64 FreeBSD 13.0-RELEASE system on ZFS, I
noticed that star would some times spuriously consider files to be full of data
holes when they do in fact not have any holes at all. A typical truss trace
looks like this:
4677: openat(AT_FDCWD,"ved",O_RDONLY,00) = 3 (0x3)
4677: lseek(3,0x0,SEEK_HOLE) = 0 (0x0)
4677: write(2,"'ved' is sparse\n",16) = 16 (0x10)
4677: lseek(3,0x0,SEEK_HOLE) = 0 (0x0)
4677: lseek(3,0x0,SEEK_DATA) ERR#6 'Device not configured'
4677: lseek(3,0x37594,SEEK_HOLE) ERR#6 'Device not configured'
4677: lseek(3,0x0,SEEK_SET) = 0 (0x0)
lseek(3, 0, SEEK_HOLE) returns 0, indicating that the file begins with a data
hole. This is unlikely as the file ved is an ELF executable which always
begins with \0177ELF. There are also spurious ENXIO returns from further lseek
calls I do not understand. Copying the file before running star makes the
problem go away:
4721: openat(AT_FDCWD,"ved",O_RDONLY,00) = 3 (0x3)
4721: lseek(3,0x0,SEEK_HOLE) = 226708 (0x37594)
4721: lseek(3,0x0,SEEK_SET) = 0 (0x0)
It is difficult to reproduce this problem as it seems to only appear some times
and on random executables.
I believe this is a severe problem as wrong output from lseek(..., SEEK_HOLE,
...) may make “smart” copying and archiving programs generate corrupt
copies/archives.
This problem looks similar to #164445, but surely that bug has already been
fixed long ago.
--
You are receiving this mail because:
You are the assignee for the bug.
