Re: Approach to quickly zeroing large XFS file (or) tool to mark XFS file extents as written

[Christoph Hellwig <hch@infradead.org>]

On Mon, Jan 06, 2025 at 11:46:39AM -0800, Darrick J. Wong wrote:
> That sounds brittle -- even if someday a FALLOC_FL_WRITE_ZEROES gets
> merged into the kernel, if anything perturbs the file mapping (e.g.
> background backup process reflinks the file) then you immediately become
> vulnerable to these crash integrity problems without notice.
> 
> (Unless you're actually getting leases on the file ranges and reacting
> appropriately when the leases break...)

They way I understood the description they have a user space program
exposing the XFS file over the network.  So if a change to the mapping
happens (e.g. due to defragmentation) they would in the worst case pay
the cost of an allocation transaction.

That is if they are really going through the normal kernel file
abstraction and don't try to bypass it by say abusing FIEMAP
information, in which case all hope is lost and the scheme has no chance
of reliably working, unless we add ioctls to expose the pNFS layouts
to userspace and they use that instead of FIEMAP.