From: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
To: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking
Date: Fri, 24 Jun 2016 09:24:46 +1000 [thread overview]
Message-ID: <20160623232446.GA12670@dastard> (raw)
In-Reply-To: <1466609236-23801-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
On Wed, Jun 22, 2016 at 05:27:08PM +0200, Christoph Hellwig wrote:
> The last patch is what started the series: XFS currently uses the
> direct I/O locking strategy for DAX because DAX was overloaded onto
> the direct I/O path. For XFS this means that we only take a shared
> inode lock instead of the normal exclusive one for writes IFF they
> are properly aligned. While this is fine for O_DIRECT which requires
> explicit opt-in from the application it's not fine for DAX where we'll
> suddenly lose expected and required synchronization of the file system
> happens to use DAX undeneath.
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....
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.
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
WARNING: multiple messages have this Message-ID (diff)
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: Fri, 24 Jun 2016 09:24:46 +1000 [thread overview]
Message-ID: <20160623232446.GA12670@dastard> (raw)
In-Reply-To: <1466609236-23801-1-git-send-email-hch@lst.de>
On Wed, Jun 22, 2016 at 05:27:08PM +0200, Christoph Hellwig wrote:
> The last patch is what started the series: XFS currently uses the
> direct I/O locking strategy for DAX because DAX was overloaded onto
> the direct I/O path. For XFS this means that we only take a shared
> inode lock instead of the normal exclusive one for writes IFF they
> are properly aligned. While this is fine for O_DIRECT which requires
> explicit opt-in from the application it's not fine for DAX where we'll
> suddenly lose expected and required synchronization of the file system
> happens to use DAX undeneath.
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....
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.
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: Fri, 24 Jun 2016 09:24:46 +1000 [thread overview]
Message-ID: <20160623232446.GA12670@dastard> (raw)
In-Reply-To: <1466609236-23801-1-git-send-email-hch@lst.de>
On Wed, Jun 22, 2016 at 05:27:08PM +0200, Christoph Hellwig wrote:
> The last patch is what started the series: XFS currently uses the
> direct I/O locking strategy for DAX because DAX was overloaded onto
> the direct I/O path. For XFS this means that we only take a shared
> inode lock instead of the normal exclusive one for writes IFF they
> are properly aligned. While this is fine for O_DIRECT which requires
> explicit opt-in from the application it's not fine for DAX where we'll
> suddenly lose expected and required synchronization of the file system
> happens to use DAX undeneath.
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....
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.
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-23 23:24 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 ` Dave Chinner [this message]
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-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
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=20160623232446.GA12670@dastard \
--to=david-fqsqvqoi3ljby3ivrkzq2a@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org \
--cc=xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org \
/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.