Bug 223287 - posix_fallocate(2) attempts to allocate impossibly large files and cannot be killed on ZFS
Summary: posix_fallocate(2) attempts to allocate impossibly large files and cannot be ...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
Depends on:
Reported: 2017-10-28 06:17 UTC by Glenn Weinberg
Modified: 2019-07-18 11:24 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Weinberg 2017-10-28 06:17:24 UTC
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.
Comment 1 Andriy Gapon freebsd_committer 2017-10-31 12:08:07 UTC
I plan on disabling posix_fallocate for ZFS altogether, same as on illumos.
Comment 2 Andriy Gapon freebsd_committer 2019-07-18 11:24:47 UTC
Actually, comment #1 was done quite a while ago, so this should be fixed.