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

[Mark Wielaard <mjw at redhat dot com>]

On Tue, 2015-05-26 at 11:13 -0400, Rich Felker wrote:
> > 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.

Well, if there are issues application/library writers certainly would
like to know or have a way to detect them. In general relying on the
glibc implementation details is a must, even if there are standards that
define some corner cases differently. It looks like the guarantees that
are needed in this case are (mostly) guaranteed by the glibc fallback
code in those cases that the kernel doesn't have direct support. At
least it seems that using posix_fallocate in this particular case is
always the better choice over ftruncate. posix_fallocate will at least
give a sensible error up front instead of just causing a SIGBUS much
later in the code.

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

Yes!

Thanks,

Mark