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. -- 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
