homepage

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/761/steps/test/logs/stdio
======================================================================
FAIL: test_fs_holes (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/home/buildbot/python/3.x.koobs-freebsd/build/Lib/test/test_posix.py", line 1003, in test_fs_holes
 self.assertLessEqual(size, os.lseek(fno, i, os.SEEK_HOLE))
AssertionError: 5 not less than or equal to 0
--
See also the issue #10142 which added this feature. I copied the nosy list of this issue.

This is likely a FreeBSD 9 kernel bug.
Using this code under python 3, on a ZFS filesystem:
"""
import os
f = open("test", "wb")
f.write(b"hello")
f.flush()
print(os.lseek(f.fileno(), 3, os.SEEK_HOLE))
"""
Under Solaris, the reply is 5, pointing to the end of the file.
Under current FreeBSD 9, it replies "3". In fact, it replies back current file offset.
This is wrong according to "lseek" man:
"""
[...]
 o If whence is SEEK_HOLE, the **offset of the start of the**
 **next hole greater than or equal to the supplied offset**
 **is returned**. The definition of a hole is provided near
 the end of the DESCRIPTION.
[...]
 A "hole" is defined as a contiguous range of bytes in a
 file, all having the value of zero, but not all zeros in a
 file are guaranteed to be represented as holes returned with
 SEEK_HOLE. Filesystems are allowed to expose ranges of zeros
 with SEEK_HOLE, but not required to. Applications can use
 SEEK_HOLE to optimise their behavior for ranges of zeros,
 but must not depend on it to find all such ranges in a file.
 **The existence of a hole at the end of every data region**
 **allows for easy programming and implies that a virtual hole**
 **exists at the end of the file.** Applications should use
 fpathconf(_PC_MIN_HOLE_SIZE) or pathconf(_PC_MIN_HOLE_SIZE)
 to determine if a filesystem supports SEEK_HOLE. See fpath-
 conf(2).
 **For filesystems that do not supply information about holes,
 the file will be represented as one entire data region.**
"""
So FreeBSD has two bugs:
1. It is giving an error if the filesystem doesn't support holes. The correct behavious SHOULD report a hole at the end of the file.
2. In a file without holes, on a filesystem supporting holes (ZFS), FreeBSD 9 is returning current file offset for SEEK_HOLE, instead of reporting offset = filesize. Consistent with the "virtual hole" at the end of the file.
koobs, can you report to FreeBSD guys?.
In the meantime we could apply a "SkipIf" to this test, to skio FreeBSD 9 (for now).
Ideas?

I'll take care of upstream and report back with PR numbers. Happy with the skipIf until resolved. Thanks for your time and patience jcea, much appreciated.

koobs, do you want the SkipIf now?. Maybe having a red buildbot can contribute push FreeBSD kernel guys :)

Give me till the end of the weekend, will ping you for the skipIf then if I haven't made progress. Thank you again.

FreeBSD Buildbot has been updated to 9.1, and the issue is solved. This was clearly a 9.0 kernel bug.
Closing bug as "Invalid".
Thanks for triaging this, Koobs.

I have just upgraded the buildbot host to FreeBSD 9.1-RELEASE and cannot see failures in the 3.x and 3.3 branches over the last couple of builds.
I have been unable to isolate the commit that fixed it, but the relevant revision log is here if anybody wants to cast an eye over it for confirmation
http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?view=log