Date: Mon, 06 Nov 2017 14:52:18 -0800 From: John Baldwin <jhb@freebsd.org> To: Ngie Cooper <yaneurabeya@gmail.com> Cc: Andriy Gapon <avg@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <188800397.5yAOiIDbtG@ralph.baldwin.cx> In-Reply-To: <5199F871-5DE2-4434-87F2-FEF88DB34037@gmail.com> References: <201711021349.vA2Dn8Yg063559@repo.freebsd.org> <5199F871-5DE2-4434-87F2-FEF88DB34037@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, November 02, 2017 10:38:49 AM Ngie Cooper wrote: > > > On Nov 2, 2017, at 06:49, Andriy Gapon <avg@FreeBSD.org> wrote: > > > > Author: avg > > Date: Thu Nov 2 13:49:08 2017 > > New Revision: 325320 > > URL: https://svnweb.freebsd.org/changeset/base/325320 > > > > Log: > > Disable posix_fallocate(2) for ZFS > > > > The generic (naive) implementation of posix_fallocate cannot provide the > > standard mandated guarantee that overwrites would never fail due to the lack > > of free space. The fundamental reason is the copy-on-write architecture > > of ZFS. Other features like compression and deduplication can also > > increase the size difference between the (pre-)allocated dummy content > > and the future content. > > > > So, until ZFS can properly implement the feature it's better to report > > that it is unsupported rather than providing an ersatz implementation. > > Please note that EINVAL is used to report that the underlying file system > > does not support the operation (POSIX.1-2008). > > > > illumos and ZoL seem to do the same. > > > > MFC after: 3 weeks > > Sponsored by: Panzura > > It’d be nice if it worked though and was reported via the file system. Posix suggests it should be, as of 2013: http://austingroupbugs.net/view.php?id=687 . > > Need to go poking around and see what’s in freebsd later on tonight. Bug filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383 . The austingroup link is just about adding a new pathconf() variable. posix_fallocate() would seem to be fundamentally incompatible with COW filesystems and can never work reliably for those. Even if you reserved N free blocks somehow until the first write, that doesn't allow multiple writes to the same file blocks while avoiding block allocation. fallocate only makes sense for overwriting filesystems like UFS. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?188800397.5yAOiIDbtG>