On Thu, Apr 30, 2020 at 11:37:03AM -0700, Darrick J. Wong wrote: > TBH I've long wondered why we flush one inode and only then check that > the icluster buffer is pinned and if so force the log? Did we do that > for some sort of forward progress guarantee? > > I looked at a3f74ffb6d144 (aka when the log force moved here from after > the iflush_cluster call) but that didn't help me figure out if there's > some subtlety here I'm missing, or if the ordering here was weird but > the weirdness didn't matter? > > TLDR: I can't tell why it's ok to move the xfs_iflush_int call down past > the log force. :/ As far as I can tell the log force is to avoid waiting for the buffer to be unpinned. This is mostly bad when using xfs_bwrite, which we still do for the xfs_reclaim_inode case, given that xfs_inode_item_push alredy checks for the pinned inode earlier, and lets the xfsaild handle the log pushing. Which means doing the log_force earlier is actually a (practially not relevant) micro-optimization as it gives the log code a few more instructions worth of time to push out and complete the log buffer. Maybe this wants to be split out into a prep patch to better document the change.
