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

["Carlos O'Donell" <carlos at redhat dot com>]

On 04/24/2015 08:53 AM, Florian Weimer wrote:
> The previous implementation could result in silent data corruption,
> and this has been observed to happen with application code.

In principle I agree with the removal of all of the fallback fallocate
code, it simply can't work reliably, and a reliable solution is ridiculously
expensive (see Rich's comments in the BZ about CAS over all the mmap'd pages).

The bug with O_APPEND files is real, and yet another reason to remove the
fallback code.

My opinion is that some of the failure modes talked about in the bugzilla
are invalid, for example having another thread or process calling truncate
is already a race condition, you don't need the fallocate fallback to
expose a race that corrupts data. The other thread might truncate after
you had written data to the file, resulting in the loss of data since
there was no synchronization. If there was synchronization then there would
be no problem since the thread calling truncate would wait for posix_fallocate
to complete before truncating.

The other side of the coin is that POSIX goes on further to say in
"2.9.7 Thread Interactions with Regular File Operations" that threads
should never see interleaving sets of file operations, but it is insane
to do anything like that because it kills performance, so you don't get
those guarantees in Linux.

What worries me though is that this change could break existing systems
that relied on this emulation to do something sensible for filesystems
that don't support fallocate. These binaries could easily be single threaded
systems with no other process touching their files and writing to filesystems
that don't support fallocate. If that is a sensible class of users, then we
need to version the interface, with the old version continuing to call the
fallback code and the new version not calling the fallback code.

In summary:

OK to checkin as long as you version the interface to prevent breaking
existing applications. Unless you can show that all filesystems a sensible
person might care about support fallocate, making versioning a waste of
time.

Thoughts?

Cheers,
Carlos.