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

[Christoph Hellwig <hch@lst.de>]

On Tue, Nov 11, 2025 at 08:33:34AM +1100, Dave Chinner wrote:
> > Not really.  FALLOC_FL_WRITE_ZEROS does hardware-offloaded zeroing.
> 
> That is not required functionality - it is an implementation
> optimisation.

It's also the reason why it exists.

> WRITE_ZEROES requires that the subsequent write must not need to
> perform filesystem metadata updates to guarantee data integrity.
> How the filesystem implements that is up to the filesystem....

No, it can;t require that.  But it is optimizing for that.

> > I think what Florian wants (although I might be misunderstanding him)
> > is an interface that will increase the file size up to the passed in
> > size, but never reduce it and lose data.
> 
> Ah, that's not a "zeroing fallocate()" like was suggested. These are
> the existing FALLOC_FL_ALLOCATE_RANGE file extension semantics.

Yes, just without allocating.

> AFAICT, this is exactly what the proposed patch implements - it
> short circuits the bit we can't guarantee (ENOSPC prevention via
> preallocation) but retains all the other aspects (non-destructive
> truncate up) when it returns success.

Yes.

> I don't see how a glibc posix_fallocate() fallback that does a
> non-desctructive truncate up though some new interface is any better
> than just having the filesystem implement ALLOCATE_RANGE without the
> ENOSPC guarantees in the first place?

For one because applications specifically probing the low-level Linux
system call will find out what is supported or not.  And Linux fallocate
has always failed when not supporting the exact semantics, while
posix_fallocate in glibc always had a (fairly broken) fallback and thus
applications can somewhat reasonable expect it to not fail.

> > They are both quite different as they both zero the entire passed in
> > range, even if it already contains data, which is completely different
> > from the posix_fallocate or fallocate FALLOC_FL_ALLOCATE_RANGE semantics
> > that leave any existing data intact.
> 
> Yes. However:
> 
> 	fallocate(fd, FALLOC_FL_WRITE_ZEROES, old_eof, new_eof - old_eof);
> 
> is exactly the "zeroing truncate up" operation that was being
> suggested. It will not overwrite any existing data, except if the
> application is racing other file extension operations with this one.

FALLOC_FL_WRITE_ZEROES is defined to zero the entire range.
FALLOC_FL_ALLOCATE_RANGE or a truncate up do not zero existing data.