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

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Jan 06, 2025 at 10:14:35PM -0800, Christoph Hellwig wrote:
> 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.

I get this funny feeling that a lot of programs might like to lease
space and get told by the kernel when someone wants/took it back.
Swapfiles and lilo ftw.

--D