Re: [PATCH 2/2] dax: move writeback calls into the filesystems

Previously calls to dax_writeback_mapping_range() for all DAX filesystems (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). dax_writeback_mapping_range() needs a struct block_device, and it used to get that from inode->i_sb->s_bdev. This is correct for normal inodes mounted on ext2, ext4 and XFS filesystems, but is incorrect for DAX raw block devices and for XFS real-time files. Instead, call dax_writeback_mapping_range() directly from the filesystem or raw block device fsync/msync code so that they can supply us with a valid block device. It should be noted that this will reduce the number of calls to dax_writeback_mapping_range() because filemap_write_and_wait_range() is called in the various filesystems for operations other than just fsync/msync. Both ext4 & XFS call filemap_write_and_wait_range() outside of ->fsync for hole punch, truncate, and block relocation (xfs_shift_file_space() && ext4_collapse_range()/ext4_insert_range()). I don't believe that these extra flushes are necessary in the DAX case. In the page cache case when we have dirty data in the page cache, that data will be actively lost if we evict a dirty page cache page without flushing it to media first. For DAX, though, the data will remain consistent with the physical address to which it was written regardless of whether it's in the processor cache or not - really the only reason I see to flush is in response to a fsync or msync so that our data is durable on media in case of a power loss. The case where we could throw dirty data out of the page cache and essentially lose writes simply doesn't exist. Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com&gt; --- fs/block_dev.c | 7 +++++++ fs/dax.c | 5 ++--- fs/ext2/file.c | 10 ++++++++++ fs/ext4/fsync.c | 10 +++++++++- fs/xfs/xfs_file.c | 12 ++++++++++-- include/linux/dax.h | 4 ++-- mm/filemap.c | 6 ------ 7 files changed, 40 insertions(+), 14 deletions(-)