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

From: Christoph Hellwig

Date: Tue Jul 07 2026 - 02:20:47 EST


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.