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

[Rui Ueyama via llvm-commits]

On Tue, Nov 14, 2017 at 4:42 AM, Mark Kettenis <mark.kettenis at xs4all.nl>
wrote:

> > 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).
>

Essentially I'd agree with you, but I believe this small Linux specific
code is still worth adding. I once accidentally created a ext2 filesystem
(instead of ext4), and even though it could be mounted as ext4, the
filesystem didn't support fallocate(2). I could also imagine that an output
directory is on fuse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171114/d8f4b0b1/attachment-0001.html>