linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mingming Cao <cmm@us.ibm.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: Wed, 4 Aug 2010 14:22:18 +1000	[thread overview]
Message-ID: <20100804042218.GW7362@dastard> (raw)
In-Reply-To: <1280878874.2334.6.camel@mingming-laptop>

On Tue, Aug 03, 2010 at 04:41:14PM -0700, Mingming Cao wrote:
> 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?

It doesn't. The 1996 usenix paper describes it well:

http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html

See section 6.2 "Performing File I/O", sepcifically the sections on
"Using Direct I/O" and "Using Multiple Processes". Quote:

"When using direct I/O, multiple readers and writers can all access
the file simultaneously. Currently, when using direct I/O and
multiple writers, we place the burden of serializing writes to the
same region of the file on the application."

This is still true 15 years later....


Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2010-08-04  4:22 UTC|newest]

Thread overview: 14+ 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-30  2:53 ` Matthew Wilcox
2010-07-30  4:53   ` Dave Chinner
2010-08-03 17:34     ` Mingming Cao
2010-08-03 22:56       ` Dave Chinner
2010-08-03 23:41         ` Mingming Cao
2010-08-04  4:22           ` Dave Chinner [this message]
2010-07-30 17:43 ` Badari Pulavarty
2010-07-30 23:13   ` Dave Chinner
2010-08-04  0:11 ` Mingming Cao
2010-08-04  3:37   ` Dave Chinner
2010-08-04  3:58     ` Dave Chinner
2010-08-04 14:55     ` Mingming Cao
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=20100804042218.GW7362@dastard \
    --to=david@fromorbit.com \
    --cc=cmm@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).