On Thu, Oct 10, 2024 at 12:01:47PM -0700, Darrick J. Wong wrote: > What if instead this took the form of a new defer_ops type? The > xfs_prepare_sb_update function would allocate a tracking object where > we'd pin the sb buffer and record which fields get changed, as well as > the new values. xfs_commit_sb_update then xfs_defer_add()s it to the > transaction and commits it. (The ->create_intent function would return > NULL so that no log item is created.) > > The ->finish_item function would then bhold the sb buffer, update the > ondisk super like how xfs_commit_sb_update does in this patch, set > XFS_SB_TRANS_SYNC, and return -EAGAIN. The defer ops would commit and > flush that transaction and call ->finish_item again, at which point it > would recompute the incore/cached geometry as necessary, bwrite the sb > buffer, and release it. > > The downside is that it's more complexity, but the upside is that the > geometry changes are contained in one place instead of being scattered > around, and the incore changes only happen if the synchronous > transaction actually gets written to disk. IOWs, the end result is the > same as what you propose here, but structured differently. That sounds overkill at first, but if we want to move all sb updates to that model more strutured infrastructure might be very useful.
