Re: posix_fallocate behavior in glibc

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 29/07/24 14:43, Christoph Hellwig wrote:
> Hi Paul,
> 
> thanks for the answer.  I don't have a current glibc assignment, so me
> directly sending a patch is probably not productive.
> 
> I don't really know which file systems benefit from doing a zeroing
> operations - after all this requires writing the data twice which usually
> actually is a bad idea unless offset by extremely suboptimal allocation
> behavior for small allocations, which got fixed in most file systems
> people actually use.  So candidates where it actually would be useful
> might be things like hfsplus.  But these are often used on cheap
> consumer media, where the double write will actually meaningfully cause
> additional write and erase cycle harming the device lifetime and long
> term performance.
> 
> Note that the kernel has a few implementations of fallocate that are
> basically a slightly more optimized implementation of this pattern
> (fat, gfs2) so some maintainers through it useful at least for
> some workloads and use cases.

We already have discussed this some years ago, where some bug were marked
as WONTFIx:

* Bug 6865 - fallback posix_fallocate() implementation is racy
* Bug 18515 - posix_fallocate disastrous fallback behavior is no longer mandated by POSIX and should be fixed
* Bug 15661 - posix_fallocate fallback code buggy and dangerous

Florian even sent a patch to remove the posix_fallocate implementations [1],
which generated a long thread of potential pitfalls of the fallback
removal [2]. 

Florian and Carlos, has anything changes in this behavior? 


[1] https://sourceware.org/legacy-ml/libc-alpha/2015-04/msg00309.html
[2] https://sourceware.org/legacy-ml/libc-alpha/2015-05/msg00058.html