Re: [PATCH v4 19/25] xfs: remove unwritten extents after preallocations in fsverity metadata

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

On Thu, Mar 12, 2026 at 02:50:57PM +0100, Andrey Albershteyn wrote:
> On 2026-03-09 18:29:14, Darrick J. Wong wrote:
> > > XFS preallocates spaces during writes. In normal I/O this space, if
> > > unused, is removed by truncate. For files with fsverity, XFS does not
> > > use truncate as fsverity metadata is stored past EOF.
> > > 
> > > After we're done with writing fsverity metadata iterate over extents in
> > > that region and remove any unwritten ones. These would be preallocation
> > > leftovers in the merkle tree holes and past fsverity descriptor.
> > > 
> > > Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
> > > ---
> 
> > There's an upper limit on the number of blocks you can unmap/free in a
> > single transaction.  Maybe move the xfs_trans_{alloc,commit} into the
> > loop body?
> > 
> > Oh wait, you skip the written extents.  Ok, so maybe just roll it after
> > you've done a bunmapi.
> 
> I see, I will add a rolling transaction. Btw, why skipping the
> written extents let's us use rolling here?

Hrmm.  At first I thought: why can't xfs_fsverity_cancel_unwritten
allocate (and commit) the transaction inside the loop body?  Then I
thought "well, it's only conditionally unmapping things, and it's sort
of a pain to allocate a transaction only then to find out if you
actually want to run one".

OTOH there could be billions of extents in the data fork, so holding the
ILOCK for that many transactions isn't a good thing because tr_write
only preallocates space for a certain number of transaction rolls.
fsverity already holds IOLOCK_EXCL so there can't be any other programs
using the file.

So now I arrive back at "The transaction allocation and commit/cancel
should be inside the loop body, since crashing midway through wouldn't
result in user-visible changes to the file data".

> > Do you need to purge the cow fork too?
> 
> hmm, what case are you thinking about here? The fsverity is written
> in past EOF region, I don't see how COW extent could be left there.
> Can they somehow be left mapped for blocks past i_size?

I was talking about speculative cow fork preallocations below i_size.
They'll eventually get purged by blockgc, but you could give the space
back once you've committed enabling the fsverity file flag.

--D