On Tue, Feb 2, 2016 at 8:46 AM, Jan Kara <jack(a)suse.cz> wrote:
On Tue 02-02-16 08:33:56, Dan Williams wrote:
> On Tue, Feb 2, 2016 at 3:17 AM, Jan Kara <jack(a)suse.cz> 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
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.