Re: posix_fallocate behavior in glibc

[Christoph Hellwig <hch@lst.de>]

Hi dear glibc maintainer,

any comments and ideas how to get glibc out of the behavior of
making file systems non-conformant by adding a broken wrapper?

On Wed, Jun 26, 2024 at 08:01:34AM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> Trond brought the glibc posix_fallocate behavior to my attention.
> 
> As a refresher, this is how Open Group defines posix_fallocate:
> 
>    The posix_fallocate() function shall ensure that any required storage
>    for regular file data starting at offset and continuing for len bytes
>    is allocated on the file system storage media. If posix_fallocate()
>    returns successfully, subsequent writes to the specified file data
>    shall not fail due to the lack of free space on the file system
>    storage media.
> 
> The glibc implementation in sysdeps/posix/posix_fallocate.c, which is
> also by sysdeps/unix/sysv/linux/posix_fallocate.c as a fallback if the
> fallocate syscall returns EOPNOTSUPP is implemented by doing single
> byte writes at intervals of min(f.f_bsize, 4096).
> 
> This assumes the writes to a file guarantee allocating space for future
> writes.  Such an assumption is false for write out place file systems
> which have been around since at least they early 1990s, but are becoming
> at lot more common in the last decode.  Native Linux examples are
> all file systems sitting on zoned devices where this is required
> behavior, but also the nilfs2 file system or the LFS mode in f2fs.
> On top of that it is fairly common for storage systems exposing
> network file system access.
> 
> How can we get rid of this glibc fallback that turns the implementations
> non-conformant and increases write amplication for no good reason?
---end quoted text---