On Fri, May 01, 2020 at 06:24:03AM -0400, Brian Foster wrote: > I recall looking at this when it was first posted and my first reaction > was that I didn't really like the interface. I decided to think about it > to see if it grew on me and then just lost track (sorry). It's not so > much passing a flag to commit as opposed to the flags not directly > controlling behavior (i.e., one flag means sync if <something> is true, > another flag means sync if <something else> is true, etc.) tends to > confuse me. I don't feel terribly strongly about it if others prefer > this pattern, but I still find the existing code more readable. > > I vaguely recall thinking it might be nice if we could dump this into > transaction state to avoid the aforementioned logic warts, but IIRC that > might not have been possible for all users of this functionality.. Moving the flag out of the transaction structure was the main motivation for this series - the fact that we need different arguments to xfs_trans_commit is just a fallout from that. The rationale is that I found it highly confusing to figure out how and where we set the sync flag vs having it obvious in the one place where we commit the transaction.
