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

[Christoph Hellwig <hch@lst.de>]

On Sat, Nov 08, 2025 at 01:30:18PM +0100, Florian Weimer wrote:
> 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.

That's a weird use of posix_fallocate, but if an interface to increase
the file without the chance of reducing it is useful that's for
sure something we could add.

> 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.

fallocate seems like an odd interface choice for that, but given that
(f)truncate doesn't have a flags argument that might still be the
least unexpected version.

> 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.

What do you think "to be used with mmap" flag could be useful for
in the file system?  For file systems mmap I/O isn't very different
from other use cases.