Oh well, lets skip DAX for now then. I still think moving the generic_write_sync call into xfs_file_dax_write/xfs_file_dio_aio_write/ xfs_file_buffered_aio_write functions would be a useful cleanup. On Mon, Mar 05, 2018 at 10:00:49AM +1100, Dave Chinner wrote: > On Fri, Mar 02, 2018 at 11:26:41PM +0100, Christoph Hellwig wrote: > > While we're at it we should probably > > also skil the generic_write_sync call for DAX pure overwrites while > > we're at it. > > Now that I've looked at it, DAX is a friggin' mess. > > We can't push the generic_write_sync() call into dax_iomap_rw() > because dax_iomap_rw is called with the inode_lock() held, and both > ext2's and ext4's ->fsync implementation can call > __generic_file_fsync() which takes the inode_lock(). Deadlock > central right there - someone is going to have to screw with ext4's > indoe sync code to before we can do this. > > Further, XFS has post-write metadata updates to do in the case of > extending writes, and hence we'd still need the call to > generic_write_sync() after we have returned from dax_iomap_rw(). I'm > thinking we'd really need a dax write IO completion callback (say in > the struct iomap_ops) to run the filesystem specific IO completions > (like the DIO path) before we can start to think about optimisations > like this for DAX for XFS.... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx ---end quoted text--- -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
