From: Dan Williams <dan.j.williams@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Jens Axboe <axboe@kernel.dk>,
Matthew Wilcox <willy@linux.intel.com>,
linux-block@vger.kernel.org,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
XFS Developers <xfs@oss.sgi.com>, Jens Axboe <axboe@fb.com>,
Al Viro <viro@ftp.linux.org.uk>,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v3 6/6] block: use dax_do_io() if blkdev_dax_capable()
Date: Wed, 17 Feb 2016 14:18:13 -0800 [thread overview]
Message-ID: <CAPcyv4g3iCL1q7FoeTwKvtqo2mLfA=mfi1K5PdmZVjU+PA-gOA@mail.gmail.com> (raw)
In-Reply-To: <20160217215420.GK14140@quack.suse.cz>
On Wed, Feb 17, 2016 at 1:54 PM, Jan Kara <jack@suse.cz> wrote:
> On Tue 16-02-16 20:34:19, Ross Zwisler wrote:
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> Setting S_DAX on an inode requires that the inode participate in the
>> DAX-fsync mechanism which expects to use the pagecache for tracking
>> potentially dirty cpu cachelines. However, dax_do_io() participates in
>> the standard pagecache sync semantics and arranges for dirty pages to be
>> flushed through the driver when a direct-IO operation accesses the same
>> ranges.
>>
>> It should always be valid to use the dax_do_io() path regardless of
>> whether the block_device inode has S_DAX set. In either case dirty
>> pages or dirty cachelines are made durable before the direct-IO
>> operation proceeds.
>
> Please no. I agree that going via DAX path for normal likely won't
> introduce new data corruption issues. But I dislike having a special
> case for block devices. Also you have no way of turning DAX off for block
> devices AFAIU and as Dave said, DAX should be opt-in, not opt-out. Note
> that you may actually want to go through the block layer for normal IO e.g.
> because you use IO cgroups to limit processes so using DAX regresses some
> functionality.
>
Sounds good.
As Ross mentioned in the cover letter, I'm fine with dropping this one
for now as we think through how to restore raw device DAX support. In
the meantime we can still force CONFIG_BLK_DEV_DAX=y for testing.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Jens Axboe <axboe@kernel.dk>,
Matthew Wilcox <willy@linux.intel.com>,
linux-block@vger.kernel.org,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
XFS Developers <xfs@oss.sgi.com>, Jens Axboe <axboe@fb.com>,
Al Viro <viro@ftp.linux.org.uk>,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v3 6/6] block: use dax_do_io() if blkdev_dax_capable()
Date: Wed, 17 Feb 2016 14:18:13 -0800 [thread overview]
Message-ID: <CAPcyv4g3iCL1q7FoeTwKvtqo2mLfA=mfi1K5PdmZVjU+PA-gOA@mail.gmail.com> (raw)
In-Reply-To: <20160217215420.GK14140@quack.suse.cz>
On Wed, Feb 17, 2016 at 1:54 PM, Jan Kara <jack@suse.cz> wrote:
> On Tue 16-02-16 20:34:19, Ross Zwisler wrote:
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> Setting S_DAX on an inode requires that the inode participate in the
>> DAX-fsync mechanism which expects to use the pagecache for tracking
>> potentially dirty cpu cachelines. However, dax_do_io() participates in
>> the standard pagecache sync semantics and arranges for dirty pages to be
>> flushed through the driver when a direct-IO operation accesses the same
>> ranges.
>>
>> It should always be valid to use the dax_do_io() path regardless of
>> whether the block_device inode has S_DAX set. In either case dirty
>> pages or dirty cachelines are made durable before the direct-IO
>> operation proceeds.
>
> Please no. I agree that going via DAX path for normal likely won't
> introduce new data corruption issues. But I dislike having a special
> case for block devices. Also you have no way of turning DAX off for block
> devices AFAIU and as Dave said, DAX should be opt-in, not opt-out. Note
> that you may actually want to go through the block layer for normal IO e.g.
> because you use IO cgroups to limit processes so using DAX regresses some
> functionality.
>
Sounds good.
As Ross mentioned in the cover letter, I'm fine with dropping this one
for now as we think through how to restore raw device DAX support. In
the meantime we can still force CONFIG_BLK_DEV_DAX=y for testing.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Jens Axboe <axboe@kernel.dk>,
Matthew Wilcox <willy@linux.intel.com>,
linux-block@vger.kernel.org,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
XFS Developers <xfs@oss.sgi.com>, Jens Axboe <axboe@fb.com>,
Al Viro <viro@ftp.linux.org.uk>,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v3 6/6] block: use dax_do_io() if blkdev_dax_capable()
Date: Wed, 17 Feb 2016 14:18:13 -0800 [thread overview]
Message-ID: <CAPcyv4g3iCL1q7FoeTwKvtqo2mLfA=mfi1K5PdmZVjU+PA-gOA@mail.gmail.com> (raw)
In-Reply-To: <20160217215420.GK14140@quack.suse.cz>
On Wed, Feb 17, 2016 at 1:54 PM, Jan Kara <jack@suse.cz> wrote:
> On Tue 16-02-16 20:34:19, Ross Zwisler wrote:
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> Setting S_DAX on an inode requires that the inode participate in the
>> DAX-fsync mechanism which expects to use the pagecache for tracking
>> potentially dirty cpu cachelines. However, dax_do_io() participates in
>> the standard pagecache sync semantics and arranges for dirty pages to be
>> flushed through the driver when a direct-IO operation accesses the same
>> ranges.
>>
>> It should always be valid to use the dax_do_io() path regardless of
>> whether the block_device inode has S_DAX set. In either case dirty
>> pages or dirty cachelines are made durable before the direct-IO
>> operation proceeds.
>
> Please no. I agree that going via DAX path for normal likely won't
> introduce new data corruption issues. But I dislike having a special
> case for block devices. Also you have no way of turning DAX off for block
> devices AFAIU and as Dave said, DAX should be opt-in, not opt-out. Note
> that you may actually want to go through the block layer for normal IO e.g.
> because you use IO cgroups to limit processes so using DAX regresses some
> functionality.
>
Sounds good.
As Ross mentioned in the cover letter, I'm fine with dropping this one
for now as we think through how to restore raw device DAX support. In
the meantime we can still force CONFIG_BLK_DEV_DAX=y for testing.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>,
Jeff Layton <jlayton@poochiereds.net>, Jens Axboe <axboe@fb.com>,
Theodore Ts'o <tytso@mit.edu>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-block@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
XFS Developers <xfs@oss.sgi.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Linux MM <linux-mm@kvack.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-ext4 <linux-ext4@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v3 6/6] block: use dax_do_io() if blkdev_dax_capable()
Date: Wed, 17 Feb 2016 14:18:13 -0800 [thread overview]
Message-ID: <CAPcyv4g3iCL1q7FoeTwKvtqo2mLfA=mfi1K5PdmZVjU+PA-gOA@mail.gmail.com> (raw)
In-Reply-To: <20160217215420.GK14140@quack.suse.cz>
On Wed, Feb 17, 2016 at 1:54 PM, Jan Kara <jack@suse.cz> wrote:
> On Tue 16-02-16 20:34:19, Ross Zwisler wrote:
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> Setting S_DAX on an inode requires that the inode participate in the
>> DAX-fsync mechanism which expects to use the pagecache for tracking
>> potentially dirty cpu cachelines. However, dax_do_io() participates in
>> the standard pagecache sync semantics and arranges for dirty pages to be
>> flushed through the driver when a direct-IO operation accesses the same
>> ranges.
>>
>> It should always be valid to use the dax_do_io() path regardless of
>> whether the block_device inode has S_DAX set. In either case dirty
>> pages or dirty cachelines are made durable before the direct-IO
>> operation proceeds.
>
> Please no. I agree that going via DAX path for normal likely won't
> introduce new data corruption issues. But I dislike having a special
> case for block devices. Also you have no way of turning DAX off for block
> devices AFAIU and as Dave said, DAX should be opt-in, not opt-out. Note
> that you may actually want to go through the block layer for normal IO e.g.
> because you use IO cgroups to limit processes so using DAX regresses some
> functionality.
>
Sounds good.
As Ross mentioned in the cover letter, I'm fine with dropping this one
for now as we think through how to restore raw device DAX support. In
the meantime we can still force CONFIG_BLK_DEV_DAX=y for testing.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-17 22:18 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 3:34 [PATCH v3 0/6] DAX fixes, move flushing calls to FS Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` [PATCH v3 1/6] block: disable block device DAX by default Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 21:55 ` Jan Kara
2016-02-17 21:55 ` Jan Kara
2016-02-17 21:55 ` Jan Kara
2016-02-17 21:55 ` Jan Kara
2016-02-17 3:34 ` [PATCH v3 2/6] ext2, ext4: only set S_DAX for regular inodes Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 21:33 ` Jan Kara
2016-02-17 21:33 ` Jan Kara
2016-02-17 21:33 ` Jan Kara
2016-02-17 21:33 ` Jan Kara
2016-02-17 3:34 ` [PATCH v3 3/6] ext4: Online defrag not supported with DAX Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 21:34 ` Jan Kara
2016-02-17 21:34 ` Jan Kara
2016-02-17 21:34 ` Jan Kara
2016-02-17 21:50 ` Ross Zwisler
2016-02-17 21:50 ` Ross Zwisler
2016-02-17 21:50 ` Ross Zwisler
2016-02-17 22:10 ` Jan Kara
2016-02-17 22:10 ` Jan Kara
2016-02-17 22:10 ` Jan Kara
2016-02-17 22:10 ` Jan Kara
2016-02-18 0:12 ` Dave Chinner
2016-02-18 0:12 ` Dave Chinner
2016-02-18 0:12 ` Dave Chinner
2016-02-18 0:12 ` Dave Chinner
2016-02-17 3:34 ` [PATCH v3 4/6] dax: give DAX clearing code correct bdev Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 21:37 ` Jan Kara
2016-02-17 21:37 ` Jan Kara
2016-02-17 21:37 ` Jan Kara
2016-02-17 3:34 ` [PATCH v3 5/6] dax: move writeback calls into the filesystems Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` [PATCH v3 6/6] block: use dax_do_io() if blkdev_dax_capable() Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 3:34 ` Ross Zwisler
2016-02-17 21:54 ` Jan Kara
2016-02-17 21:54 ` Jan Kara
2016-02-17 21:54 ` Jan Kara
2016-02-17 21:54 ` Jan Kara
2016-02-17 22:18 ` Dan Williams [this message]
2016-02-17 22:18 ` Dan Williams
2016-02-17 22:18 ` Dan Williams
2016-02-17 22:18 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPcyv4g3iCL1q7FoeTwKvtqo2mLfA=mfi1K5PdmZVjU+PA-gOA@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=axboe@kernel.dk \
--cc=bfields@fieldses.org \
--cc=david@fromorbit.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=jlayton@poochiereds.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=matthew.r.wilcox@intel.com \
--cc=ross.zwisler@linux.intel.com \
--cc=tytso@mit.edu \
--cc=viro@ftp.linux.org.uk \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@linux.intel.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.