From: Zheng Liu <gnehzuil.liu@gmail.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>,
linux-ext4@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org, tytso@mit.edu, hch@infradead.org
Subject: Re: A huge latency in ext4 and xfs because of stable page write
Date: Thu, 13 Dec 2012 10:30:26 +0800 [thread overview]
Message-ID: <20121213023026.GB5185@gmail.com> (raw)
In-Reply-To: <20121212194710.GA9453@blackbox.djwong.org>
Hi Darrick,
On Wed, Dec 12, 2012 at 11:47:10AM -0800, Darrick J. Wong wrote:
> On Wed, Dec 12, 2012 at 01:13:32PM +0800, Zheng Liu wrote:
> > On Wed, Dec 12, 2012 at 03:49:49PM +1100, Dave Chinner wrote:
> > [cut...]
> > > > > > 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
> >
> > Thanks for pointing out. So now it seems that only I can do is to
> > present a proposal to revert stable page write temporarily because it
> > causes a huge latency for some applications.
>
> Hrm... just to be clear, is your complaint that you have one of these
> checksum-happy disks and overwrites are slow on it, or that you have a regular
> SATA disk that doesn't require stable pages and you don't want to take the
> speed hit?
>
> If it's the second, then let's just push the bdi flag thing upstream. Given
> your comments a couple of days ago, I'm pretty sure it's the second, but I
> figured I ought to clarify the record. :)
Yes, it's the second. In our product system we have a large number of
SATA disks that don't require stable pages. So that would be great if
we have a method to turn on/off stable page.
>
> I haven't posted new patches because I've been busy writing a fix for ext3.
> It seems to be working, so I'll clean it up and send out a new series.
Cool! We are looking forward the new patch series. :-)
Regards,
- Zheng
prev parent reply other threads:[~2012-12-13 2:17 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
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 [this message]
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=20121213023026.GB5185@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.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).