On Thu, Oct 10, 2024 at 10:05:53AM -0400, Brian Foster wrote: > Ok, so we don't want geometry changes transactions in the same CIL > checkpoint as alloc related transactions that might depend on the > geometry changes. That seems reasonable and on a first pass I have an > idea of what this is doing, but the description is kind of vague. > Obviously this fixes an issue on the recovery side (since I've tested > it), but it's not quite clear to me from the description and/or logic > changes how that issue manifests. > > Could you elaborate please? For example, is this some kind of race > situation between an allocation request and a growfs transaction, where > the former perhaps sees a newly added AG between the time the growfs > transaction commits (applying the sb deltas) and it actually commits to > the log due to being a sync transaction, thus allowing an alloc on a new > AG into the same checkpoint that adds the AG? This is based on the feedback by Dave on the previous version: https://lore.kernel.org/linux-xfs/Zut51Ftv%2F46Oj386@xxxxxxxxxxxxxxxxxxx/ Just doing the perag/in-core sb updates earlier fixes all the issues with my test case, so I'm not actually sure how to get more updates into the check checkpoint. I'll try your exercisers if it could hit that.
