On Thu, Jul 19, 2018 at 02:36:34PM -0700, Darrick J. Wong wrote: > > That sounds reasonable to me. We can always change behavior in a > > subsequent patch. IIRC the only issue is that intent recovery code has > > no way to carry dop_low mode around without a transaction. It currently > > passes around a dfops for each intent. Hmm, perhaps we can have the > > caller just allocate a transaction, pass it to the recovery helpers for > > reservation and then just keep rolling it rather than have each helper > > allocate a transaction anew. I'll look into it, or let me know if you > > have any other thoughts/ideas. > > That could get tricky, since each log intent item type allocates its own > transaction with some context-dependent reservation and resblks. Rolling > our way through the intent items would require us to calculate the max > reservation size and resblks for all the items beforehand for the > initial _trans_alloc, which would be kinda messy to avoid having a flags > field. For now we can just keep that state in a separate variable, e.g.: bool low_space_mode = (tp->t_flags & XFS_TRANS_LOW_SPACE); ... if (low_space_mode) other_tp->t_flags |= XFS_TRANS_LOW_SPACE; Not too pretty but I wouldn't spend to much time on this low space mode, which fundamentally is a horribly band aid and should eventually go away once we've fixed up our space reservations for real. -- 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
