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=3D223287 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, ev= en 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" t= hat subsequent writes to the allocated area in the file will not fail due to la= ck 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 iss= ue 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 writ= es 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. --=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-223287-8>