[PATCH] D39464: Define fs::allocate_file which preallocates disk blocks.

Mark Kettenis via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 13 11:42:10 PST 2017


> From: Rafael Avila de Espindola <rafael.espindola at gmail.com>
> Date: Mon, 13 Nov 2017 10:21:13 -0800
> 
> Kamil Rytarowski <n54 at gmx.com> writes:
> 
> > On 13.11.2017 18:19, Rafael Avila de Espindola wrote:
> >> Kamil Rytarowski via Phabricator <reviews at reviews.llvm.org> writes:
> >> 
> >>> krytarowski added inline comments.
> >>>
> >>>
> >>> ================
> >>> Comment at: llvm/lib/Support/Unix/Path.inc:436
> >>>        return std::error_code(Err, std::generic_category());
> >>> +    return make_error_code(errc::function_not_supported);
> >>>    }
> >>> ----------------
> >>> NetBSD needs `ftruncate`(2) as a fallback for `posix_fallocate`(2).
> >>>
> >>> In the default setup `posix_fallocate`() returns EOPNOTSUPP.
> >> 
> >> Will ftruncate allocate space on netbsd? Note that it is OK for
> >> allocate_file to fail. The user then has to use a buffer and write(2)
> >> instead of mmap for output.
> >> 
> >> Cheers,
> >> Rafael
> >> 
> >
> > ftruncate(2)/NetBSD as an extension extends area and makes it
> > zero-filled. It's equivalent to lseek(2) + write(2).
> 
> Cool, so an mmap of the file after a ftruncate will never crash because
> of disk full, correct?

I seriously doubt ftruncate(2) behaves differently on NetBSD.  There
is nothing in the man page that suggests this, and users would
probably scream if creating sparse files was broken.

> If so we could use use ftruncate on netbsd as a special case, similar to
> the special case we have for OS X.

I still think OS-specific code should be avoided when a reasonable
portable alternative exists.  Maybe OS X is important enough that a
performance regressions in unacceptable.  But the Linux-specific code
provides no benefit over the posix_fallocate(2) code for the vast
majority of use cases where output files will be created on
filesystems that support fallocate(2).


More information about the llvm-commits mailing list