lkml.org 
[lkml]   [2015]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3 13/15] block, dax: make dax mappings opt-in by default
From
On Tue, Nov 3, 2015 at 12:20 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Nov 02, 2015 at 11:35:04PM -0800, Dan Williams wrote:
>> On Mon, Nov 2, 2015 at 4:32 PM, Dave Chinner <david@fromorbit.com> wrote:
[..]
>> Only in the mmap path:
>
> which means blkdev_direct_IO() is now always going to go down the
> dax_do_io() path for any driver with a ->direct_access method rather
> than the direct IO path, regardless of whether DAX is enabled on the
> device or not.
>
> That really seems wrong to me - you've replace explicit "is DAX
> enabled" checks with "is DAX possible" checks, and so DAX paths are
> used regardless of whether DAX is enabled or not. And it's not
> obvious why this is done, nor is it now obvious how DAX interacts
> with the block device.
>
> This really seems like a step backwards to me.

I think the reason it is not obvious is the original justification for
the bypass as stated in commit bbab37ddc20b "block: Add support for
DAX reads/writes to block devices" was:

"instead of allocating a DIO and a BIO"

It turns out it's faster and as far as I can tell semantically
equivalent to the __blockdev_direct_IO() path. The DAX mmap path in
comparison has plenty of sharp edges and semantic differences that
would be avoided by turning off DAX.

I'm not opposed to also turning off dax_do_io() when S_DAX is clear,
but I don't currently see the point. At the very least I need to add
the above comments to the code, but do you still think opt-in DAX is a
backwards step?


\
 
 \ /
  Last update: 2015-11-04 00:21    [W:0.081 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site