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