From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@lst.de> Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking Date: Sat, 25 Jun 2016 09:00:45 +1000 [thread overview] Message-ID: <20160624230045.GG12670@dastard> (raw) In-Reply-To: <20160624072612.GA22205@lst.de> On Fri, Jun 24, 2016 at 09:26:12AM +0200, Christoph Hellwig wrote: > On Fri, Jun 24, 2016 at 09:24:46AM +1000, Dave Chinner wrote: > > Except we did that *intentionally* - by definition there is no > > cache to bypass with DAX and so all IO is "direct". That, combined > > with the fact that all Linux filesystems except XFS break the POSIX > > exclusive writer rule you are quoting to begin with, it seemed > > pointless to enforce it for DAX.... > > No file system breaks the exclusive writer rule - most filesystem > don't make writers atomic vs readers. > > More importantly every other filesystem (well there only are ext2 > and ext4..) exludes DAX writers against other DAX writers. > > > So, before taking any patches to change that behaviour in XFS, a > > wider discussion about the policy needs to be had. I don't think > > we should care about POSIX here - if you have an application that > > needs this serialisation, turn off DAX. That's why I made it a > > per-inode inheritable flag and why the mount option will go away > > over time. > > Sorry, but this is simply broken - allowing apps to opt-in behavior > (e.g. like we're using O_DIRECT) is always fine. Requriring > filesystem-specific tuning that has affect outside the app to get > existing documented behavior is not how to design APIs. Using DAX is an *admin decision*, not an application decision. Indeed, it's a mount option right now, and that's most definitely not something the application can turn on or off! Inode flags allow the admin to decide that two apps working on the same filesystem can use (or not use) DAX independently, rather than needing to put them on different filesystems. > Maybe we'll need to opt-in to use DAX for mmap, but giving the same > existing behavior for read and write and avoiding a copy to the pagecache > is an obvious win. You can't use DAX just for mmap. It's an inode scope behaviour - once it's turned on, all accesses to that inode - regardless of user interface - must use DAX. It's all or nothing, not a per file descript/mmap context option. Cheers, Dave. -- Dave Chinner david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@lst.de> Cc: linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org, xfs@oss.sgi.com Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking Date: Sat, 25 Jun 2016 09:00:45 +1000 [thread overview] Message-ID: <20160624230045.GG12670@dastard> (raw) In-Reply-To: <20160624072612.GA22205@lst.de> On Fri, Jun 24, 2016 at 09:26:12AM +0200, Christoph Hellwig wrote: > On Fri, Jun 24, 2016 at 09:24:46AM +1000, Dave Chinner wrote: > > Except we did that *intentionally* - by definition there is no > > cache to bypass with DAX and so all IO is "direct". That, combined > > with the fact that all Linux filesystems except XFS break the POSIX > > exclusive writer rule you are quoting to begin with, it seemed > > pointless to enforce it for DAX.... > > No file system breaks the exclusive writer rule - most filesystem > don't make writers atomic vs readers. > > More importantly every other filesystem (well there only are ext2 > and ext4..) exludes DAX writers against other DAX writers. > > > So, before taking any patches to change that behaviour in XFS, a > > wider discussion about the policy needs to be had. I don't think > > we should care about POSIX here - if you have an application that > > needs this serialisation, turn off DAX. That's why I made it a > > per-inode inheritable flag and why the mount option will go away > > over time. > > Sorry, but this is simply broken - allowing apps to opt-in behavior > (e.g. like we're using O_DIRECT) is always fine. Requriring > filesystem-specific tuning that has affect outside the app to get > existing documented behavior is not how to design APIs. Using DAX is an *admin decision*, not an application decision. Indeed, it's a mount option right now, and that's most definitely not something the application can turn on or off! Inode flags allow the admin to decide that two apps working on the same filesystem can use (or not use) DAX independently, rather than needing to put them on different filesystems. > Maybe we'll need to opt-in to use DAX for mmap, but giving the same > existing behavior for read and write and avoiding a copy to the pagecache > is an obvious win. You can't use DAX just for mmap. It's an inode scope behaviour - once it's turned on, all accesses to that inode - regardless of user interface - must use DAX. It's all or nothing, not a per file descript/mmap context option. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-06-24 23:00 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-22 15:27 xfs: untangle the direct I/O and DAX path, fix DAX locking Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig [not found] ` <1466609236-23801-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-06-22 15:27 ` [PATCH 1/8] xfs: don't pass ioflags around in the ioctl path Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 2/8] xfs: kill ioflags Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 3/8] xfs: remove s_maxbytes enforcement in xfs_file_read_iter Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 4/8] xfs: split xfs_file_read_iter into buffered and direct I/O helpers Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 5/8] xfs: stop using generic_file_read_iter for direct I/O Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 6/8] xfs: direct calls in the direct I/O path Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` [PATCH 7/8] xfs: split direct I/O and DAX path Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig [not found] ` <1466609236-23801-8-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-29 2:53 ` Darrick J. Wong 2016-09-29 2:53 ` Darrick J. Wong 2016-09-29 2:53 ` Darrick J. Wong 2016-09-29 8:38 ` aio completions vs file_accessed race, was: " Christoph Hellwig 2016-09-29 8:38 ` Christoph Hellwig 2016-09-29 20:18 ` Christoph Hellwig 2016-09-29 20:18 ` Christoph Hellwig 2016-09-29 20:18 ` Christoph Hellwig 2016-09-29 20:18 ` Christoph Hellwig 2016-09-29 20:33 ` Darrick J. Wong 2016-09-29 20:33 ` Darrick J. Wong 2016-06-22 15:27 ` [PATCH 8/8] xfs: fix locking for DAX writes Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-22 15:27 ` Christoph Hellwig 2016-06-23 14:22 ` Boaz Harrosh 2016-06-23 14:22 ` Boaz Harrosh 2016-06-23 23:24 ` xfs: untangle the direct I/O and DAX path, fix DAX locking Dave Chinner 2016-06-23 23:24 ` Dave Chinner 2016-06-23 23:24 ` Dave Chinner 2016-06-24 1:14 ` Dan Williams 2016-06-24 1:14 ` Dan Williams 2016-06-24 7:13 ` Dave Chinner 2016-06-24 7:13 ` Dave Chinner 2016-06-24 7:31 ` Christoph Hellwig 2016-06-24 7:31 ` Christoph Hellwig 2016-06-24 7:26 ` Christoph Hellwig 2016-06-24 7:26 ` Christoph Hellwig 2016-06-24 7:26 ` Christoph Hellwig 2016-06-24 23:00 ` Dave Chinner [this message] 2016-06-24 23:00 ` Dave Chinner 2016-06-28 13:10 ` Christoph Hellwig 2016-06-28 13:10 ` Christoph Hellwig 2016-06-28 13:10 ` Christoph Hellwig [not found] ` <20160628131059.GA30475-jcswGhMUV9g@public.gmane.org> 2016-06-28 13:27 ` Boaz Harrosh 2016-06-28 13:27 ` Boaz Harrosh 2016-06-28 13:27 ` Boaz Harrosh [not found] ` <57727B27.7060104-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org> 2016-06-28 13:39 ` Christoph Hellwig 2016-06-28 13:39 ` Christoph Hellwig 2016-06-28 13:39 ` Christoph Hellwig [not found] ` <20160628133928.GB31283-jcswGhMUV9g@public.gmane.org> 2016-06-28 13:56 ` Boaz Harrosh 2016-06-28 13:56 ` Boaz Harrosh 2016-06-28 13:56 ` Boaz Harrosh [not found] ` <5772820E.2080403-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org> 2016-06-28 15:39 ` Christoph Hellwig 2016-06-28 15:39 ` Christoph Hellwig 2016-06-28 15:39 ` Christoph Hellwig [not found] ` <20160628153925.GA2643-jcswGhMUV9g@public.gmane.org> 2016-06-29 12:23 ` Boaz Harrosh 2016-06-29 12:23 ` Boaz Harrosh 2016-06-29 12:23 ` Boaz Harrosh
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=20160624230045.GG12670@dastard \ --to=david@fromorbit.com \ --cc=hch@lst.de \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-nvdimm@ml01.01.org \ --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: linkBe 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.