On Tue, Feb 02, 2016 at 09:46:21AM -0800, Dan Williams wrote: > 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() The point is that filesystems have lots of different get_block operations, and the right one to use depends not just on the inode, but also upon what VFS function is being called, and in some filesystems the phase of the moon, or the file open flags (so even inode->i_ops->get_block is wrong; file->f_ops->get_block would be better, but of course we've lost that by the point we're doing writeback). I now realise that basing DAX around get_block & buffer_heads was a mistake. I think the Right Solution (not for 4.5) is to ask filesystems to populate the radix tree. A flow somewhat like this: 1. VFS or VM calls filesystem (eg ->fault()) 2. Filesystem calls DAX (eg dax_fault()) 3. DAX looks in radix tree, finds no information. 4. DAX calls (NEW!) mapping->a_ops->populate_pfns 5. Filesystem looks up its internal data structure (eg extent tree) and calls dax_create_pfns() (see giant patch from yesterday, only instead of passing a get_block_t, the filesystem has already filled in a bh which describes the entire extent that this access happens to land in). 6. DAX continues to take care of calling bdev_direct_access() from dax_create_pfns(). After we have that step done, we can look at what it would take to avoid calling bdev_direct_access for non-block-based filesystems. That looks to me like just calling dax_add_pfn_entries() from their ->populate_pfns implementation. And we introduce a CONFIG_BLOCK ifdef around dax_create_pfns(), dax_clear_blocks() and dax_zero_page_range(). Or maybe modify dax_zero_page_range() to use the radix tree as above, since it's probably a useful helper function. Once we have buffer_head usage confined to a fairly small part of DAX, we can look at replacing it with a more appropriate data structure with better-defined contents. -- 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
