Re: transaction reservations for deleting of shared extents

[Christoph Hellwig <hch@lst.de>]

On Wed, Apr 12, 2017 at 04:06:12PM -0700, Darrick J. Wong wrote:
> So I think the problem you're seeing here is that just prior to (3g) we
> have the most deferred items (EFIs, specifically) attached to this
> transaction at any point in the whole operation.  There can be so many
> EFIs that we use up the log reservation and blow the ASSERT.

Yes.  I think that's exactly what I'm seing, except that rmap isn't
part of the game.

> > I still don't have a good idea how to fix this, though.  One idea
> > would be to prevent mixing different items, but I think being able
> > to mix them was one of your goals with the defer infrastructure rewrite.
> 
> Yes, we have to be able to perform several different types of updates
> in one defer_ops so that we can execute CoW remappings atomically.

In one defer_ops, but I don't see anything preventing us from starting
a new chained transaction everytime we move from one type to another.