Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 May 2021 16:52:21 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 256205] lseek() with SEEK_HOLE some times wrongly reports holes on ZFS
Message-ID:  <bug-256205-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256205

            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 ZF=
S, 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)        =3D 3 (0x3)
 4677: lseek(3,0x0,SEEK_HOLE)                    =3D 0 (0x0)
 4677: write(2,"'ved' is sparse\n",16)           =3D 16 (0x10)
 4677: lseek(3,0x0,SEEK_HOLE)                    =3D 0 (0x0)
 4677: lseek(3,0x0,SEEK_DATA)                    ERR#6 'Device not configur=
ed'
 4677: lseek(3,0x37594,SEEK_HOLE)                ERR#6 'Device not configur=
ed'
 4677: lseek(3,0x0,SEEK_SET)                     =3D 0 (0x0)


lseek(3, 0, SEEK_HOLE) returns 0, indicating that the file begins with a da=
ta
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 l=
seek
calls I do not understand.  Copying the file before running star makes the
problem go away:

 4721: openat(AT_FDCWD,"ved",O_RDONLY,00)        =3D 3 (0x3)
 4721: lseek(3,0x0,SEEK_HOLE)                    =3D 226708 (0x37594)
 4721: lseek(3,0x0,SEEK_SET)                     =3D 0 (0x0)

It is difficult to reproduce this problem as it seems to only appear some t=
imes
and on random executables.

I believe this is a severe problem as wrong output from lseek(..., SEEK_HOL=
E,
...) may make =E2=80=9Csmart=E2=80=9D copying and archiving programs genera=
te corrupt
copies/archives.

This problem looks similar to #164445, but surely that bug has already been
fixed long ago.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256205-227>