Date: Sat, 28 Oct 2017 06:17:24 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 223287] posix_fallocate(2) attempts to allocate impossibly large files and cannot be killed on ZFS Message-ID: <bug-223287-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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@FreeBSD.org Reporter: glenn.weinberg@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223287-8>