* Christoph Hellwig:

On Mon, Nov 10, 2025 at 10:31:40AM +0100, Christoph Hellwig wrote:

quoted

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.

quoted

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.

The usual way to pass extra flags was the flats at for the *at syscalls.
truncate doesn't have that, and I wonder if there would be uses for
that?  Because if so that feels like the right way to add that feature.
OTOH a quick internet search only pointed to a single question about it,
which was related to other confusion in the use of (f)truncate.

While adding a new system call can be rather cumbersome, the advantage
would be that we could implement the "only increase file size" flag
in common code and it would work on all file systems for kernels that
support the system call.

There are some references to ftruncateat:

  <https://codesearch.debian.net/search?q=ftruncateat&literal=1>

I don't have a particularly strong opinion on the choice of interface.
I can't find anything in the Austin Group tracker that suggests that
they are considering standardizing ftruncateat without a flags argument.

Thanks,
Florian