All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Boaz Harrosh <boaz-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
	Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking
Date: Tue, 28 Jun 2016 17:39:25 +0200	[thread overview]
Message-ID: <20160628153925.GA2643@lst.de> (raw)
In-Reply-To: <5772820E.2080403-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>

On Tue, Jun 28, 2016 at 04:56:30PM +0300, Boaz Harrosh wrote:
> Actually with O_APPEND each write request should write a different region
> of the file, there are no overlapping writes. And no issue of which version of the
> write came last and got its data written.

You have one fd for multiple threads or processes (it doesn't matter if
you're using O_APPEND or not), and all of them write to it.

i_size is only updated once the write finishes, so having multiple
concurrent writes will mean multiple records go into the same regions.
Now to be fair in current XFS writes beyond i_size will always take
the lock exclusively, so for this case we will not get concurrent
writes and thus data corruption anyway.  But if you have a cycling
log that gets overwritten (say a database journal) we're back to
square one.

> I still don't see how an application can use the fact that two writers
> will not give them mixed records. And surly it does not work on a shared
> FS. So I was really wondering if you know of any such app

If it doesn't work for two threads using the same fd on a shared fs
the fs is broken.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Dave Chinner <david@fromorbit.com>,
	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: Tue, 28 Jun 2016 17:39:25 +0200	[thread overview]
Message-ID: <20160628153925.GA2643@lst.de> (raw)
In-Reply-To: <5772820E.2080403@plexistor.com>

On Tue, Jun 28, 2016 at 04:56:30PM +0300, Boaz Harrosh wrote:
> Actually with O_APPEND each write request should write a different region
> of the file, there are no overlapping writes. And no issue of which version of the
> write came last and got its data written.

You have one fd for multiple threads or processes (it doesn't matter if
you're using O_APPEND or not), and all of them write to it.

i_size is only updated once the write finishes, so having multiple
concurrent writes will mean multiple records go into the same regions.
Now to be fair in current XFS writes beyond i_size will always take
the lock exclusively, so for this case we will not get concurrent
writes and thus data corruption anyway.  But if you have a cycling
log that gets overwritten (say a database journal) we're back to
square one.

> I still don't see how an application can use the fact that two writers
> will not give them mixed records. And surly it does not work on a shared
> FS. So I was really wondering if you know of any such app

If it doesn't work for two threads using the same fd on a shared fs
the fs is broken.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org,
	Christoph Hellwig <hch@lst.de>,
	xfs@oss.sgi.com
Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking
Date: Tue, 28 Jun 2016 17:39:25 +0200	[thread overview]
Message-ID: <20160628153925.GA2643@lst.de> (raw)
In-Reply-To: <5772820E.2080403@plexistor.com>

On Tue, Jun 28, 2016 at 04:56:30PM +0300, Boaz Harrosh wrote:
> Actually with O_APPEND each write request should write a different region
> of the file, there are no overlapping writes. And no issue of which version of the
> write came last and got its data written.

You have one fd for multiple threads or processes (it doesn't matter if
you're using O_APPEND or not), and all of them write to it.

i_size is only updated once the write finishes, so having multiple
concurrent writes will mean multiple records go into the same regions.
Now to be fair in current XFS writes beyond i_size will always take
the lock exclusively, so for this case we will not get concurrent
writes and thus data corruption anyway.  But if you have a cycling
log that gets overwritten (say a database journal) we're back to
square one.

> I still don't see how an application can use the fact that two writers
> will not give them mixed records. And surly it does not work on a shared
> FS. So I was really wondering if you know of any such app

If it doesn't work for two threads using the same fd on a shared fs
the fs is broken.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2016-06-28 15:39 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
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 [this message]
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=20160628153925.GA2643@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=boaz-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org \
    --cc=david-FqsqvQoI3Ljby3iVrkZq2A@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.