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
