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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256205

--- Comment #10 from Robert Clausecker <fuz@fuz.su> ---
Ok, it was a stale zpool cache file.  Regenerated that.  Now zdb spits out for
the defective file:

# zdb -ddddd tau/usr/home 158868 
Dataset tau/usr/home [ZPL], ID 166, cr_txg 156, 1.02G, 73710 objects, rootbp
DVA[0]=<0:1480e5000:1000> DVA[1]=<0:34b8519000:1000> [L0 DMU objset] fletcher4
uncompressed unencrypted LE contiguous unique double size=1000L/1000P
birth=754593L/754593P fill=73710
cksum=fdbb2e5f4:2c554aff465c:42583346179396:463202c0625bcf73

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
    158868    1   128K   128K      0     512   128K    0.00  ZFS plain file
                                               168   bonus  System attributes
        dnode flags: USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED 
        dnode maxblkid: 0
        path    /fuz/src/schily-2021-05-19/psmake/smake
        uid     1001
        gid     0
        atime   Mon May 31 17:27:05 2021
        mtime   Mon May 31 17:27:05 2021
        ctime   Mon May 31 17:27:05 2021
        crtime  Mon May 31 17:27:05 2021
        gen     754481
        mode    100755
        size    172444
        parent  125362
        links   1
        pflags  40800000104
Indirect blocks:

And for a copy of that file:

# zdb -ddddd tau/usr/home 165839
Dataset tau/usr/home [ZPL], ID 166, cr_txg 156, 1.02G, 73711 objects, rootbp
DVA[0]=<0:1481bd000:1000> DVA[1]=<0:34b85d5000:1000> [L0 DMU objset] fletcher4
uncompressed unencrypted LE contiguous unique double size=1000L/1000P
birth=754604L/754604P fill=73711
cksum=f5c0e13c8:2bd5f9eb9464:4306ac91d2ee06:48548583efa66ed7

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
    165839    2   128K   128K    72K     512   256K  100.00  ZFS plain file
                                               168   bonus  System attributes
        dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED 
        dnode maxblkid: 1
        path    /fuz/smake
        uid     1001
        gid     1001
        atime   Mon May 31 17:37:23 2021
        mtime   Mon May 31 17:37:23 2021
        ctime   Mon May 31 17:37:23 2021
        crtime  Mon May 31 17:37:23 2021
        gen     754604
        mode    100755
        size    172444
        parent  2
        links   1
        pflags  40800000104
Indirect blocks:
               0 L1  0:279c393000:1000 20000L/1000P F=2 B=754604/754604
cksum=89ddba81fd:1f641e2304c6e:3959b7adc4672c0:60f134ca72c7adee
               0  L0 0:1aec965000:b000 20000L/b000P F=1 B=754604/754604
cksum=162256381a3f:1e6cd61da6d0818:ab4c29600d5f7235:84ff2b8da3762f93
           20000  L0 0:1aec959000:5000 20000L/5000P F=1 B=754604/754604
cksum=84074ce4c6c:5f268b4e9e1cc5:83823b486e8a59f7:97b671e2edc43809

                segment [0000000000000000, 0000000000040000) size  256K

There's two more things I noticed: (a) the defective file is written through a
nullfs mount and (b) the file is "cured" after a while, i.e. no longer pretends
to be sparse.  This is independent of sync calls, but seems to happen after
some hours of letting the FS idle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.