Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]

[Rich Felker <dalias at libc dot org>]

On Tue, May 26, 2015 at 11:12:15AM +0200, Florian Weimer wrote:
> On 05/22/2015 12:18 PM, Mark Wielaard wrote:
> > On Mon, 2015-05-18 at 12:43 +0200, Florian Weimer wrote:
> >> Another very recent example is here:
> >>
> >> https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-May/004868.html
> >>
> >>> This suggests that people actually rely on the current allocation
> >>> behavior.  Combined with my previous analysis that applications will
> >>> start to fail if we remove the fallback and return EINVAL, I now think
> >>> we need to keep the allocation loop.
> > 
> > I should point out that the above patch isn't in elfutils yet. It is
> > waiting on how this discussion turns out.
> > 
> > At the moment we simply use ftruncate. The problem that is solved by
> > using posix_fallocate is that we are about the write to the memory of an
> > mmapped file. Since ftruncate doesn't guarantee that the backing store
> > is really there we risk getting a SIGBUS if the disk is full and we
> > write to a memory area that hasn't been allocated yet. Since this is in
> > library code, we cannot simply catch the SIGBUS. And we cannot use
> > fallocate since that doesn't guarantee that the backing store is really
> > allocated since it depends on whether the underlying file system support
> > fallocate.
> 
> posix_fallocate does not guarantee this, either.  See my patch with the
> documentation update.  Compression, COW, thin provision all can result
> in ENOSPC.

These are all buggy, non-conforming implementations. That doesn't mean
users can't use them, but when applications malfunction, it's because
they're using a low-quality, wrong implementation, not because the
application has a bug. When the implementation intentionally cuts
corners on correctness, it's not the application's job to make up for
it.

> And obviously, there can be other I/O errors.

That's faulty hardware which is not covered by the specification.
Technically, having faulty hardware is non-conforming too.

> If you absolutely, truly need to use mmap, we need either have to
> provide a way to intercept SIGBUS (perhaps à la SHEâthe technology is
> there, it's just not available to C code in a deeply nested library
> right now), or another mmap flag that prevents the kernel from sending
> SIGBUS, and some way to tell if a mapping had been subject to write
> errors (perhaps revive msync(MS_ASYNC)?).

This would be really nice. Handling SIGBUS is not a viable approach
because it's not library-safe and difficult to make thread-safe.

Rich