Re: transaction reservations for deleting of shared extents

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Feb 21, 2017 at 10:07:47AM +0100, Christoph Hellwig wrote:
> 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..

Yes, "adjust refcount up/down" is a higher level operation than the
other deferred ops, but in order to keep the operation atomic and a sane
limit on the number of RUIs being logged to the head transaction it was
necessary to do it this way.

I considered simply establishing an upper limit on the number of
refcount tree updates that one could perform in a single go -- it
survives in the form of the error-injection knob in that function that
artificially cuts off after 2 updates.  Everything seems to work just
fine with that in place, though rather more slowly when the refcountbt
has a lot of small entries.

Anyway, I could go instrument the kernel to measure nr_ops and
transaction reservation usage for the refcountbt updates to see what
tweaks might be necessary.

--D

> > 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---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html