On Fri, Jun 13, 2014 at 09:44:41AM +1000, Dave Chinner wrote: > On Thu, Jun 12, 2014 at 07:13:29AM -0700, Christoph Hellwig wrote: > > There doesn't really seem anything XFS specific here, so instead > > of wiring up ->aio_fsync I'd implement IOCB_CMD_FSYNC in fs/aio.c > > based on the workqueue and ->fsync. > > I really don't know whether the other ->fsync methods in other > filesystems can stand alone like that. I also don't have the > time to test that it works properly on all filesystems right now. Of course they can, as shown by various calls to vfs_fsync_range that is nothing but a small wrapper around ->fsync. I'm pretty sure if you Cc linux-fsdevel you'll find plenty of testers. -fsdevel and -man should get a Cc anyway when implementing an ABI that had it's constants defines but never was implemented properly. Talking about documentation: The kernel aio manpages (io_*.2) seems to not really be very useful, mostly because they don't explain how to set up the iocbs. Michael, any idea how to get started to improve this? > Also, doing this implementation in fs/aio.c would mean we can't > optimise it to reduce things like log forces by splitting up the > work of concurrent fsyncs into a single log force of the highest > LSN of the batch of fsyncs being run. We also want to be able to do > "background fsync" where latency doesn't matter and we only want to > trickle them out rather than issue them as fast as we possibly can. It didn't really sound like you were aiming for that. But in that case the current implementation is still useful as a generic_file_aio_fsync as suggested by Brian. > So I really don't see this as the infrastructure solution that > everyone uses. It could be made a generic method with the filesystem > passing the workqueue to use to generic_aio_fsync(), but for XFS I > see it turning into something much more complex and optimised... Why not have a common workqueue? In fact we already have a common workqueue to call ->fsync from aio code to implement aio O_SYNC anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
