[Bug 256205] lseek() with SEEK_HOLE some times wrongly reports holes on ZFS

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: bugs@FreeBSD.org
          Reporter: fuz@fuz.su

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.