From: Dave Chinner <david@fromorbit.com>
To: Raz <raziebe@gmail.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: HUGE XFS regression in 2.6.32 upto 2.6.38
Date: Tue, 12 Apr 2011 19:52:33 +1000 [thread overview]
Message-ID: <20110412095233.GZ31057@dastard> (raw)
In-Reply-To: <BANLkTinyBD7Zm3DvoYCVfYJkF36yXz6hOA@mail.gmail.com>
On Tue, Apr 12, 2011 at 10:58:53AM +0300, Raz wrote:
> Christoph Hello
> I am testing 2.6.38 with AIM benchmark.
> I compared 2.6.38 to 2.6.27 and I noticed that 2.6.27 is much better
> than 2.6.38 when
> doing sync random writes test over an xfs regular file over native
> Linux partition on top common sata disk.
> I git bisected the problem and I reached this SHA1:
> commit 13e6d5cdde0e785aa943810f08b801cadd0935df
> Author: Christoph Hellwig <hch@lst.de>
> Date: Mon Aug 31 21:00:31 2009 -0300
>
> xfs: merge fsync and O_SYNC handling
>
> The guarantees for O_SYNC are exactly the same as the ones we need to
> make for an fsync call (and given that Linux O_SYNC is O_DSYNC the
> equivalent is fdadatasync, but we treat both the same in XFS), except
> with a range data writeout. Jan Kara has started unifying these two
> path for filesystems using the generic helpers, and I've started to
> look at XFS.
> ...
>
>
> The bellow two tests presents the how different performance is before and patch:
> #test 16) bisect 11
> ------------------------------------------------------------------------------------------------------------
> Test Test Elapsed Iteration Iteration Operation
> Number Name Time (sec) Count Rate (loops/sec) Rate (ops/sec)
> ------------------------------------------------------------------------------------------------------------
> 1 sync_disk_rw 30.71 19 0.61869 1583.85
> Sync Random Disk Writes (K)/second
> ------------------------------------------------------------------------------------------------------------
That's clearly showing that your sync writes are not hitting the
disk. IOWs, the sync writes are not synchronous at all. There is
no way a single SATA drive can do >1500 writes to stable storage
per second.
IOWs, before this fix, sync writes were broken on your hardware.
> #test 17 ) bisect 12
> ------------------------------------------------------------------------------------------------------------
> 1 sync_disk_rw 69.05 1 0.01448 37.07
> Sync Random Disk Writes (K)/second
> ------------------------------------------------------------------------------------------------------------
And that's pretty tpyical for a SATA drive where sync writes are
actually hitting the platter correctly.
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:[~2011-04-12 9:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 7:58 HUGE XFS regression in 2.6.32 upto 2.6.38 Raz
2011-04-12 9:52 ` Dave Chinner [this message]
2011-04-12 11:19 ` Raz
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=20110412095233.GZ31057@dastard \
--to=david@fromorbit.com \
--cc=raziebe@gmail.com \
--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