All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com,
	sandeen@sandeen.net
Subject: Re: [PATCH] dio: track and serialise unaligned direct IO
Date: Tue, 03 Aug 2010 16:41:14 -0700	[thread overview]
Message-ID: <1280878874.2334.6.camel@mingming-laptop> (raw)
In-Reply-To: <20100803225658.GB26402@dastard>

On Wed, 2010-08-04 at 08:56 +1000, Dave Chinner wrote:
> On Tue, Aug 03, 2010 at 10:34:25AM -0700, Mingming Cao wrote:
> > On Fri, 2010-07-30 at 14:53 +1000, Dave Chinner wrote:
> > > On Thu, Jul 29, 2010 at 08:53:24PM -0600, Matthew Wilcox wrote:
> > > > On Fri, Jul 30, 2010 at 08:45:16AM +1000, Dave Chinner wrote:
> > > > > If we get two unaligned direct IO's to the same filesystem block
> > > > > that is marked as a new allocation (i.e. buffer_new), then both IOs will
> > > > > zero the portion of the block they are not writing data to. As a
> > > > > result, when the IOs complete there will be a portion of the block
> > > > > that contains zeros from the last IO to complete rather than the
> > > > > data that should be there.
> ....
> > > I don't want any direct IO for XFS to go through the page cache -
> > > unaligned or not. using the page cache for the unaligned blocks
> > > would also be much worse for performance that this method because it
> > > turns unaligned direct IO into 3 IOs - the unaligned head block, the
> > > aligned body and the unaligned tail block. It would also be a
> > > performance hit you take on every single dio, whereas this way the
> > > hit is only taken when an overlap is detected.
> > 
> > Does this problem also possible for DIO and non AIO case? (Ext4 case
> > this only happy with AIO+DIO+unaligned).  If not, could we simply force
> > unaligned AIO+DIO to be synchronous? Still direct IO...
> 
> There is nothing specific to AIO about this bug. XFS (at least)
> allows concurrent DIO writes to the same inode regardless of whether
> they are dispatched via AIO or multiple separate threads and so the
> race condition exists outside just the AIO context...
> 

Okay..yeah ext4 prevent direct IO write to the same inode from multiple
threads, so this is not a issue for non-aio case.

How does XFS serialize direct IO (aligned) to the same file offset(or
overlap) from multiple threads?

Mingming


WARNING: multiple messages have this Message-ID (diff)
From: Mingming Cao <cmm@us.ibm.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com,
	sandeen@sandeen.net, Matthew Wilcox <matthew@wil.cx>
Subject: Re: [PATCH] dio: track and serialise unaligned direct IO
Date: Tue, 03 Aug 2010 16:41:14 -0700	[thread overview]
Message-ID: <1280878874.2334.6.camel@mingming-laptop> (raw)
In-Reply-To: <20100803225658.GB26402@dastard>

On Wed, 2010-08-04 at 08:56 +1000, Dave Chinner wrote:
> On Tue, Aug 03, 2010 at 10:34:25AM -0700, Mingming Cao wrote:
> > On Fri, 2010-07-30 at 14:53 +1000, Dave Chinner wrote:
> > > On Thu, Jul 29, 2010 at 08:53:24PM -0600, Matthew Wilcox wrote:
> > > > On Fri, Jul 30, 2010 at 08:45:16AM +1000, Dave Chinner wrote:
> > > > > If we get two unaligned direct IO's to the same filesystem block
> > > > > that is marked as a new allocation (i.e. buffer_new), then both IOs will
> > > > > zero the portion of the block they are not writing data to. As a
> > > > > result, when the IOs complete there will be a portion of the block
> > > > > that contains zeros from the last IO to complete rather than the
> > > > > data that should be there.
> ....
> > > I don't want any direct IO for XFS to go through the page cache -
> > > unaligned or not. using the page cache for the unaligned blocks
> > > would also be much worse for performance that this method because it
> > > turns unaligned direct IO into 3 IOs - the unaligned head block, the
> > > aligned body and the unaligned tail block. It would also be a
> > > performance hit you take on every single dio, whereas this way the
> > > hit is only taken when an overlap is detected.
> > 
> > Does this problem also possible for DIO and non AIO case? (Ext4 case
> > this only happy with AIO+DIO+unaligned).  If not, could we simply force
> > unaligned AIO+DIO to be synchronous? Still direct IO...
> 
> There is nothing specific to AIO about this bug. XFS (at least)
> allows concurrent DIO writes to the same inode regardless of whether
> they are dispatched via AIO or multiple separate threads and so the
> race condition exists outside just the AIO context...
> 

Okay..yeah ext4 prevent direct IO write to the same inode from multiple
threads, so this is not a issue for non-aio case.

How does XFS serialize direct IO (aligned) to the same file offset(or
overlap) from multiple threads?

Mingming

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

  reply	other threads:[~2010-08-03 23:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29 22:45 [PATCH] dio: track and serialise unaligned direct IO Dave Chinner
2010-07-29 22:45 ` Dave Chinner
2010-07-30  2:53 ` Matthew Wilcox
2010-07-30  2:53   ` Matthew Wilcox
2010-07-30  4:53   ` Dave Chinner
2010-07-30  4:53     ` Dave Chinner
2010-08-03 17:34     ` Mingming Cao
2010-08-03 17:34       ` Mingming Cao
2010-08-03 22:56       ` Dave Chinner
2010-08-03 22:56         ` Dave Chinner
2010-08-03 23:41         ` Mingming Cao [this message]
2010-08-03 23:41           ` Mingming Cao
2010-08-04  4:22           ` Dave Chinner
2010-08-04  4:22             ` Dave Chinner
2010-07-30 17:43 ` Badari Pulavarty
2010-07-30 17:43   ` Badari Pulavarty
2010-07-30 23:13   ` Dave Chinner
2010-07-30 23:13     ` Dave Chinner
2010-08-04  0:11 ` Mingming Cao
2010-08-04  0:11   ` Mingming Cao
2010-08-04  3:37   ` Dave Chinner
2010-08-04  3:37     ` Dave Chinner
2010-08-04  3:58     ` Dave Chinner
2010-08-04  3:58       ` Dave Chinner
2010-08-04 14:55     ` Mingming Cao
2010-08-04 14:55       ` Mingming Cao
2010-08-05  1:02       ` Dave Chinner
2010-08-05  1:02         ` Dave Chinner

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=1280878874.2334.6.camel@mingming-laptop \
    --to=cmm@us.ibm.com \
    --cc=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=sandeen@sandeen.net \
    --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.