Date: Mon, 31 May 2021 15:50:18 +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-b7hu21N6q4@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 #11 from Alan Somers <asomers@FreeBSD.org> --- Now we're getting somewhere. * zdb shows a file that is completely sparse; it contains no data * nullfs is involved. Maybe your newly written file is getting cached by nullfs in the VM cache a= nd not flushed to ZFS until "some hours of letting the FS idle". And maybe nu= llfs forwards the FIOSEEKHOLE ioctl to ZFS without first flushing the file. That would explain why you're getting bad results. To test this theory, try writing the bad file again, then do "fsync <path/to/file>" and then examine it with zdb and star. If it's dense, then that supports my theory. --=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-b7hu21N6q4>