Re: ftruncate() after FICLONERANGE costs 300-600us/file, ~10x more than the clone itself

[Christoph Hellwig <hch@infradead.org>]

On Mon, Jul 06, 2026 at 10:56:51PM -0700, Darrick J. Wong wrote:
> XFS zeroes the tail block when you truncate down, which causes an out of
> place write.

All the file systems do it (or at least should).  But somehow we
manage to be slower.

I wonder if we hit the filemap_write_and_wait_range case in
xfs_vn_setattr_size due to a non-uptodate i_disk_size for this
workload somehow?  Although reflink should update i_disk_size
properly.

> 
> Assuming src.dat is the fully written 90000 byte file, can you
> 
> $ xfs_io -c "reflink src.dat 86016 86016 0" dest.dat
> 
> to link only the eof-block into dest.dat and keep its file size at
> 90000?

Only doing the reflink block aligned and copying data for partial
blocks should indeed always be faster.  But I wonder if we have
some dragons lurking in the truncate down path.