On Tue, Feb 02, 2016 at 09:47:37AM -0800, Dan Williams wrote: > On Tue, Feb 2, 2016 at 9:46 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > On Tue, Feb 2, 2016 at 9:34 AM, Ross Zwisler > > <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > >> On Tue, Feb 02, 2016 at 09:10:24AM -0800, Dan Williams wrote: > >>> On Tue, Feb 2, 2016 at 8:46 AM, Jan Kara <jack@xxxxxxx> wrote: > >>> > On Tue 02-02-16 08:33:56, Dan Williams wrote: > >>> >> On Tue, Feb 2, 2016 at 3:17 AM, Jan Kara <jack@xxxxxxx> wrote: > >>> >> [..] > >>> >> > I see, thanks for explanation. So I'm OK with changing what is stored in > >>> >> > the radix tree to accommodate this use case but my reservation that we IHMO > >>> >> > have other more pressing things to fix remains... > >>> >> > >>> >> We don't need pfns in the radix to support XFS RT configurations. > >>> >> Just call get_blocks() again and use the sector, or am I missing > >>> >> something? > >>> > > >>> > You are correct. But if you decide to pay the cost of additional > >>> > get_block() call, you only need the dirty tag in the radix tree and nothing > >>> > else. So my understanding was that the whole point of games with radix tree > >>> > is avoiding this extra get_block() calls for fsync(). > >>> > > >>> > >>> DAX-fsync() is already a potentially expensive operation to cover data > >>> durability guarantees for DAX-unaware applications. A DAX-aware > >>> application is going to skip fsync, and the get_blocks() cost, to do > >>> cache management itself. > >>> > >>> Willy pointed out some other potential benefits, assuming a suitable > >>> replacement for the protections afforded by the block-device > >>> percpu_ref counter can be found. However, optimizing for the > >>> DAX-unaware-application case seems the wrong motivation to me. > >> > >> Oh, no, the primary issue with calling get_block() in the fsync path isn't > >> performance. It's that we don't have any idea what get_block() function to > >> call. > >> > >> The fault handler calls all come from the filesystem directly, so they can > >> easily give us an appropriate get_block() function pointer. But the > >> dax_writeback_mapping_range() calls come from the generic code in > >> mm/filemap.c, and don't know what get_block() to pass in. > >> > >> During one iteration I had the calls to dax_writeback_mapping_range() > >> happening in the filesystem fsync code so that it could pass in get_block(), > >> but Dave Chinner pointed out that this misses other paths in the filesystem > >> that need to have things flushed via a call to filemap_write_and_wait_range(). > >> > >> In yet another iteration of this series I tried adding get_block() to struct > >> inode_operations so that I could access it from what is now > >> dax_writeback_mapping_range(), but this was shot down as well. > > > > Ugh, and we can't trigger it from where a filesystem normally syncs a > > block device, becauDid you tryse we lose track of the inode radix > > [ sorry, copy paste error ] > > block device, because we lose track of the inode radix > > > information at that level. > > > > What a about a super_operation? That seems the right level, given > > we're currently doing: > > > > inode->i_sb->s_bdev > > > > ...it does not seem terrible to instead do: > > > > inode->i_sb->s_op->get_block() This seems promising. I'll try and code it up. -- 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
