Re: transaction reservations for deleting of shared extents

[Christoph Hellwig <hch@lst.de>]

On Mon, Feb 20, 2017 at 05:43:56PM -0800, Darrick J. Wong wrote:
> Hmmmm.  refcountbt updates should all be processed as deferred ops,
> which means that each logical update ("increase refcount of blocks
> 3-300") should be getting its own transaction.

Yes, but we'd still need to figure out how much to allocate for that
transaction.

> The function xfs_refcount_still_have_space tries to guess when we're
> getting close to using up all the log reservation by assuming that each
> refcount update will eventually use 32 bytes of the transaction
> reservation, though it's hard to know precisely what the results of
> formatting the log items will be.

I guess it's getting that estimate wrong.  It's also pretty weird
and different from how we reserve space for transactions everywhere
else in XFS..

> When it thinks we're out of transaction space it'll signal a partial
> completion, which (should) cause the defer_ops mechanism to log an RUD
> and a new RUI, then roll the transaction and start again.  I speculate
> that my guess of 32 bytes per refcountbt update is not correct. :(
> 
> Can you reproduce it easily?  IIRC xfs/140 should exercise some of this
> mechanism.

I personally can't reproduce it easily, but there is a QA setup that
reproduces it reliably, although it takes quite some time. I think I
can send you the reproducer, but it might require the right hardware
to hit the race, given that I can't actually reproduce it.

> 
> --D
---end quoted text---