[Bug 223287] posix_fallocate(2) attempts to allocate impossibly large files and cannot be killed on ZFS

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 223287
           Summary: posix_fallocate(2) attempts to allocate impossibly
                    large files and cannot be killed on ZFS
           Product: Base System
           Version: 11.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: glenn.weinberg at intel.com

ZFS allows posix_fallocate(2) to attempt to reserve any amount of space, even
if the request is larger than the entire capacity of the pool. While it may be
true that in theory pools are "infinitely" expandable in ZFS, this behavior is
not in the spirit of posix_fallocate(2), which is supposed to "guarantee" that
subsequent writes to the allocated area in the file will not fail due to lack
of space. (There has been previous discussion of the validity of
posix_fallocate(2) on COW file systems such as ZFS, but that is not the issue
here.)

Furthermore, posix_fallocate(2) operates by repeatedly writing to the file. The
ZFS behavior of writing forever might be tolerable, albeit not ideal, if the
posix_fallocate(2) call were interruptible, but the entire sequence of writes
is performed under a lock, so once the unsupportably large request has
commenced, there is no way to stop it short of a hard reboot.

Returning ENOSPC if the requested allocation is larger than the current pool
size (or file system size for UFS) seems like a relatively simple check to
make, and a reasonable compromise between the spirit of posix_fallocate(2) and
the theoretical expandability of ZFS.

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