From: Dave Chinner <david@fromorbit.com>
To: linux-ext4@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org, tytso@mit.edu, hch@infradead.org,
darrick.wong@oracle.com
Subject: Re: A huge latency in ext4 and xfs because of stable page write
Date: Wed, 12 Dec 2012 15:49:49 +1100 [thread overview]
Message-ID: <20121212044948.GW16353@dastard> (raw)
In-Reply-To: <20121212041803.GA29427@gmail.com>
On Wed, Dec 12, 2012 at 12:18:03PM +0800, Zheng Liu wrote:
> On Tue, Dec 11, 2012 at 10:17:07PM +1100, Dave Chinner wrote:
> > On Tue, Dec 11, 2012 at 04:45:21PM +0800, Zheng Liu wrote:
> > > Hi all,
> > >
> > > At Tao Bao we meet a problem in our product system which causes a huge latency
> > > because of stable page write. This problem is easy to reproduce in a testing
> > > environment, and I can reproduce it in my desktop with a SATA disk. Here is the
> > > fio config file that is used to reproduce this problem.
> > >
> > > config file
> > > -----------
> > > [global]
> > > iodepth=1
> > > directory=/mnt/sda3
> > > direct=0
> > > group_reporting
> > > thread
> > > fallocate=0
> > > runtime=120
> > >
> > > [log-append]
> > > ioengine=sync
> > > rw=write
> > > bs=1k
> >
> > Sub-page sized IO. That's guaranteed to have noticable IO latency
> > anomalies, regardless of stable data pages. If you are just
> > doing appending writes, then you can easily buffer them till you
> > have a page of data to write and avoid the problem altogether.
>
> Hi Dave,
>
> Thanks for your reply. I agree with you that the application still
> could be improved. But, unfortunately, the real life is that we cannot
> change the application. We couldn't convince the application developers
> that they need to change their program to adapt to the latest kernel
> because the latest kernel has a new feature that is not useful for them.
> That is unacceptable for them. :-(
Too bad for them, then. The kernel can't give everyone a pony....
> > > Hence, I wonder whether or not we could revert stable page write temporarily.
> > > After it is improved, we could add it back again.
> >
> > The plan is to turn it off for filesystems/devices that don't
> > require it. That list of devices will grow in future, so you
> > probably should plan to handle latencies in the application
> > properly...
>
> I wonder whether we can provide a sysctl to turn on/off stable page
> write. At least we need to give sysadmin an opportunity to control it.
That's already been considered and discarded because turning off
stable pages on devices that require it will cause validation or
data corruption problems. The discussion was for these patches (and
I think a followup series as well):
http://www.spinics.net/lists/linux-fsdevel/msg59421.html
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2012-12-12 4:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 8:45 A huge latency in ext4 and xfs because of stable page write Zheng Liu
2012-12-11 11:17 ` Dave Chinner
2012-12-12 4:18 ` Zheng Liu
2012-12-12 4:49 ` Dave Chinner [this message]
2012-12-12 5:13 ` Zheng Liu
2012-12-12 7:23 ` Stefan Ring
2012-12-12 8:17 ` Zheng Liu
2012-12-12 23:07 ` Dave Chinner
2012-12-12 19:47 ` Darrick J. Wong
2012-12-13 2:30 ` Zheng Liu
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=20121212044948.GW16353@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--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).