public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: yy <yy@xspring.net>
To: "Dave Chinner" <david@fromorbit.com>
Cc: bfoster <bfoster@redhat.com>,
	"Eric Sandeen" <sandeen@sandeen.net>, xfs <xfs@oss.sgi.com>
Subject: Re: XFS buffer IO performance is very poor
Date: Fri, 13 Feb 2015 10:20:44 +0800	[thread overview]
Message-ID: <tencent_CE304F969859276F366B2DA3@qq.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2113 bytes --]

Dave,
Thank you very much for your explanation.


I hit this issue when run MySQL on XFS. Direct IO is very import for MySQL on XFS,but I can’t found any document explanation this problem.Maybe this will cause great confusion for other MySQL users also, so maybe this problem should be explained in XFS document.


Best regards,
yy


原始邮件
发件人:Dave Chinnerdavid@fromorbit.com
收件人:yyyy@xspring.net
抄送:xfsxfs@oss.sgi.com; Eric Sandeensandeen@sandeen.net; bfosterbfoster@redhat.com
发送时间:2015年2月13日(周五) 05:04
主题:Re: XFS buffer IO performance is very poor


On Thu, Feb 12, 2015 at 02:59:52PM +0800, yy wrote:  In functionxfs_file_aio_read, will requestXFS_IOLOCK_SHARED lock  for both direct IO and buffered IO:  so write will prevent read in XFS.   However, in function generic_file_aio_read for ext3, will not  lockinode-i_mutex, so write will not prevent read in ext3.   I think this maybe the reason of poor performance for XFS. I do  not know if this is a bug, or design flaws of XFS. This is a bug and design flaw in ext3, and most other Linux filesystems. Posix states that write() must execute atomically and so no concurrent operation that reads or modifies data should should see a partial write. The linux page cache doesn't enforce this - a read to the same range as a write can return partially written data on page granularity, as read/write only serialise on page locks in the page cache. XFS is the only Linux filesystem that actually follows POSIX requirements here - the shared/exclusive locking guarantees that a buffer write completes wholly before a read is allowed to access the data. There is a down side - you can't run concurrent buffered reads and writes to the same file - if you need to do that then that's what direct IO is for, and coherency between overlapping reads and writes is then the application's problem, not the filesystem... Maybe at some point in the future we might address this with ranged IO locks, but there really aren't many multithreaded programs that hit this issue... Cheers, Dave. -- Dave Chinner david@fromorbit.com

[-- Attachment #1.2: Type: text/html, Size: 3532 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

             reply	other threads:[~2015-02-13  2:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13  2:20 yy [this message]
2015-02-13 13:46 ` XFS buffer IO performance is very poor Carlos Maiolino
  -- strict thread matches above, loose matches on Subject: below --
2015-02-12  6:59 yy
2015-02-12 21:04 ` Dave Chinner
2015-02-12  5:30 yy
2015-02-11  7:39 yy
2015-02-11 13:35 ` Brian Foster
2015-02-11 16:08 ` Eric Sandeen

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=tencent_CE304F969859276F366B2DA3@qq.com \
    --to=yy@xspring.net \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --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