Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-09 Thread Ross Zwisler
On Tue, Feb 09, 2016 at 05:01:34PM +0100, Jan Kara wrote: > On Tue 09-02-16 10:43:53, Jan Kara wrote: > > On Mon 08-02-16 12:55:24, Dan Williams wrote: > > > On Mon, Feb 8, 2016 at 12:18 PM, Dave Chinner wrote: > > > [..] > > > >> Setting aside the current block zeroing problem you seem to assumin

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-09 Thread Jan Kara
On Tue 09-02-16 10:43:53, Jan Kara wrote: > On Mon 08-02-16 12:55:24, Dan Williams wrote: > > On Mon, Feb 8, 2016 at 12:18 PM, Dave Chinner wrote: > > [..] > > >> Setting aside the current block zeroing problem you seem to assuming > > >> that DAX will always be faster and that may not be true at

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-09 Thread Jan Kara
On Mon 08-02-16 12:55:24, Dan Williams wrote: > On Mon, Feb 8, 2016 at 12:18 PM, Dave Chinner wrote: > [..] > >> Setting aside the current block zeroing problem you seem to assuming > >> that DAX will always be faster and that may not be true at a media > >> level. Waiting years for some applicat

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Dan Williams
On Mon, Feb 8, 2016 at 12:58 PM, Jeff Moyer wrote: > Dan Williams writes: > >> I agree the mount option needs to die, and I fully grok the reasoning. >> What I'm concerned with is that a system using fully-DAX-aware >> applications is forced to incur the overhead of maintaining *sync >> semanti

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Jeff Moyer
Dan Williams writes: > I agree the mount option needs to die, and I fully grok the reasoning. > What I'm concerned with is that a system using fully-DAX-aware > applications is forced to incur the overhead of maintaining *sync > semantics, periodic sync(2) in particular, even if it is not rely

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Dan Williams
On Mon, Feb 8, 2016 at 12:18 PM, Dave Chinner wrote: [..] >> Setting aside the current block zeroing problem you seem to assuming >> that DAX will always be faster and that may not be true at a media >> level. Waiting years for some applications to determine if DAX makes >> sense for their use ca

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Dave Chinner
On Mon, Feb 08, 2016 at 12:18:11AM -0800, Dan Williams wrote: > On Sun, Feb 7, 2016 at 1:50 PM, Dave Chinner wrote: > > On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > >> On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler > >> wrote: > >> > Previously calls to dax_writeback_mapping_ran

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Dan Williams
On Mon, Feb 8, 2016 at 10:31 AM, Ross Zwisler wrote: > On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: >> The proposal: make applications explicitly request DAX semantics with >> a new MAP_DAX flag and fail if DAX is unavailable. Document that a >> successful MAP_DAX request mandate

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Ross Zwisler
On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > The proposal: make applications explicitly request DAX semantics with > a new MAP_DAX flag and fail if DAX is unavailable. Document that a > successful MAP_DAX request mandates that the application assumes > responsibility for cpu cac

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Ross Zwisler
On Mon, Feb 08, 2016 at 11:48:50AM +0100, Jan Kara wrote: > On Sun 07-02-16 00:19:13, Ross Zwisler wrote: > > Previously calls to dax_writeback_mapping_range() for all DAX filesystems > > (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). > > dax_writeback_mapping_range() needs

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Jan Kara
On Sun 07-02-16 00:19:13, Ross Zwisler wrote: > Previously calls to dax_writeback_mapping_range() for all DAX filesystems > (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). > dax_writeback_mapping_range() needs a struct block_device, and it used to > get that from inode->i_sb-

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-08 Thread Dan Williams
On Sun, Feb 7, 2016 at 1:50 PM, Dave Chinner wrote: > On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: >> On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler >> wrote: >> > Previously calls to dax_writeback_mapping_range() for all DAX filesystems >> > (ext2, ext4 & xfs) were centralized in

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-07 Thread Dave Chinner
On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler > wrote: > > Previously calls to dax_writeback_mapping_range() for all DAX filesystems > > (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). > > dax_writeback_mapping_

Re: [PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-07 Thread Dan Williams
On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler wrote: > Previously calls to dax_writeback_mapping_range() for all DAX filesystems > (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). > dax_writeback_mapping_range() needs a struct block_device, and it used to > get that from inod

[PATCH 2/2] dax: move writeback calls into the filesystems

2016-02-06 Thread Ross Zwisler
Previously calls to dax_writeback_mapping_range() for all DAX filesystems (ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range(). dax_writeback_mapping_range() needs a struct block_device, and it used to get that from inode->i_sb->s_bdev. This is correct for normal inodes mounted on