Date: Mon, 31 May 2021 15:40:05 +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-jXWYRLZOzP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256205-227@https.bugs.freebsd.org/bugzilla/> References: <bug-256205-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256205 --- 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=20 Dataset tau/usr/home [ZPL], ID 166, cr_txg 156, 1.02G, 73710 objects, rootbp DVA[0]=3D<0:1480e5000:1000> DVA[1]=3D<0:34b8519000:1000> [L0 DMU objset] fl= etcher4 uncompressed unencrypted LE contiguous unique double size=3D1000L/1000P birth=3D754593L/754593P fill=3D73710 cksum=3Dfdbb2e5f4: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 attribut= es dnode flags: USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED=20 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]=3D<0:1481bd000:1000> DVA[1]=3D<0:34b85d5000:1000> [L0 DMU objset] fl= etcher4 uncompressed unencrypted LE contiguous unique double size=3D1000L/1000P birth=3D754604L/754604P fill=3D73711 cksum=3Df5c0e13c8: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 attribut= es dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED=20 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=3D2 B=3D754604/754604 cksum=3D89ddba81fd:1f641e2304c6e:3959b7adc4672c0:60f134ca72c7adee 0 L0 0:1aec965000:b000 20000L/b000P F=3D1 B=3D754604/754604 cksum=3D162256381a3f:1e6cd61da6d0818:ab4c29600d5f7235:84ff2b8da3762f93 20000 L0 0:1aec959000:5000 20000L/5000P F=3D1 B=3D754604/754604 cksum=3D84074ce4c6c:5f268b4e9e1cc5:83823b486e8a59f7:97b671e2edc43809 segment [0000000000000000, 0000000000040000) size 256K There's two more things I noticed: (a) the defective file is written throug= h a nullfs mount and (b) the file is "cured" after a while, i.e. no longer pret= ends to be sparse. This is independent of sync calls, but seems to happen after some hours of letting the FS idle. --=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-jXWYRLZOzP>