When we free a metadata extent, we record it in the per-AG busy extent array so that it is not re-used before the freeing transaction hits the disk. This array is fixed size, so when it overflows we
Having the patches merged into one certainly helps with readability. This version also passes xfsqa fine while I had some problems with that with the delayed logging tree. I'm a bit confused by that.
Oh, and while I'm at it: I'd move the list_del_init(&busyp->list); from xfs_trans_free_busy into xfs_alloc_clear_busy, we also do the list insertation inside xfs_alloc_busy_insert, so that makes it s
Yeah, I can't explain the root cause, either. Short story: at the time I did this I was getting desperate - I'd been trying to work out the failure you reported for three days and had tried just abou
Been looking at this a bit and I have a theory: - a tid is not actually unique to a xfs_trans structure, if we call xfs_trans_dup a single xlog_ticket, and with that the tid is re-used by multiple tr
Good point, and an angle I had missed. The problem case is not re-allocation of the busy extent, it's the subsequent freeing of that extent that is already busy. i.e. we've done "free - alloc - free"