[Bug libc/18515] posix_fallocate disastrous fallback behavior is no longer mandated by POSIX and should be fixed

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18515

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Pat from comment #0)
> The fallback behavior of posix_fallocate() is a disaster. The entire point
> of this function is to improve system performance by allowing applications
> to preallocate large extents, helping the O/S to minimize on-disk
> fragmentation.

While it is true that there is a performance aspect to calling posix_fallocate,
I have never read anywhere that the purpose of the function was to improve
system performance (preallocation).

The standards description of posix_fallocate talks explicitly about making sure
the space you need is present, and that is the key thing here, the backing
store is allocated. Therefore subsequent writes don't fail, and mmap followed
by memory reads and writes don't SIGBUS.

Having said that, I agree that the fallback code is racy, and seeing Issue 7 of
POSIX provide a way out is good.

Are you not worried that removing the fallback code will simply push the
problem into the application? Where you will get lots of bespoke attempts to
ensure the file has backing store allocated by doing writes? Should glibc
provide a posix_fallocate_ng that continues to use the fallback so applications
that need the fallback can use it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.