On Wed, Feb 24, 2021 at 12:45:29PM -0800, Darrick J. Wong wrote: > On Tue, Feb 23, 2021 at 02:34:37PM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Move it to xfs_bio_io.c as we are about to add new async cache flush > > functionality that uses bios directly, so all this stuff should be > > in the same place. Rename the function to xfs_flush_bdev() to match > > the xfs_rw_bdev() function that already exists in this file. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > I don't get why it's necessary to consolidate the synchronous flush > function with the (future) async flush, since all the sync flush callers > go through a buftarg, including the log. All this seems to do is shift > pointer dereferencing into callers. > > Why not make the async flush function take a buftarg? Because we pretty much got rid of the buffer/buftarg abstraction from the log IO code completely by going direct to bios. The async flush goes direct to bios like the rest of the log code does. And given that xfs_blkdev_issue_flush() is just a one line wrapper around the blkdev interface, it just seems totally weird to wrap it differently to other interfaces that go direct to the bios and block devices. Part of the problem here is that we've completely screwed up the separation/abstraction of the log from the xfs_mount and buftargs. The log just doesn't use buftargs anymore except as a holder of the log bdev, and the only other interaction it has with them is when the metadata device cache needs to be invalidated after log recovery and during unmount. It just doesn't make sense to me to have bdev flush interfaces that the log uses hidden behind an abstraction that the rest of the log subsystem doesn't use... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
