Re: [RFC] xfs: fake fallocate success for always CoW inodes

[Florian Weimer]

* Christoph Hellwig:

> On Thu, Nov 06, 2025 at 05:31:28PM +0100, Florian Weimer wrote:
>> It's been a few years, I think, and maybe we should drop the allocation
>> logic from posix_fallocate in glibc?  Assuming that it's implemented
>> everywhere it makes sense?
>
> I really think it should go away.  If it turns out we find cases where
> it was useful we can try to implement a zeroing fallocate in the kernel
> for the file system where people want it.  gfs2 for example currently
> has such an implementation, and we could have somewhat generic library
> version of it.

Sorry, I remember now where this got stuck the last time.

This program:

#include <fcntl.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

int
main(void)
{
  FILE *fp = tmpfile();
  if (fp == NULL)
    abort();
  int fd = fileno(fp);
  posix_fallocate(fd, 0, 1);
  char *p = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  *p = 1;
}

should not crash even if the file system does not support fallocate.
I hope we can agree on that.  I expect avoiding SIGBUS errors because
of insufficient file size is a common use case for posix_fallocate.
This use is not really an optimization, it's required to get mmap
working properly.

If we can get an fallocate mode that we can use as a fallback to
increase the file size with a zero flag argument, we can definitely
use that in posix_fallocate (replacing the fallback path on kernels
that support it).  All local file systems should be able to implement
that (but perhaps not efficiently).  Basically, what we need here is a
non-destructive ftruncate.

Maybe add two flags, one for the ftruncate replacement, and one that
instructs the file system that the range will be used with mmap soon?
I expect this could be useful information to the file system.  We
wouldn't use it in posix_fallocate, but applications calling fallocate
directly might.

Christoph, is this something you could help with?