From: torn5 <torn5@shiftmail.org>
To: Ted Ts'o <tytso@mit.edu>
Cc: Josef Bacik <josef@redhat.com>,
Jon Leighton <j@jonathanleighton.com>,
linux-ext4@vger.kernel.org
Subject: Re: Severe slowdown caused by jbd2 process
Date: Sat, 22 Jan 2011 02:11:34 +0100 [thread overview]
Message-ID: <4D3A2EC6.3020700@shiftmail.org> (raw)
In-Reply-To: <20110121235641.GM3043@thunk.org>
On 01/22/2011 12:56 AM, Ted Ts'o wrote:
> On Fri, Jan 21, 2011 at 09:31:45AM -0500, Josef Bacik wrote:
>
>> Yup, whatever you are doing in your webapp is making your database do lots of
>> fsyncs, which is going to suck. If you are on a battery backed system or just
>> don't care if you lose your database and rather it be faster you can mount your
>> ext4 fs with -o nobarrier. Thanks,
>>
> Note that if you don't use -o barrier on ext3, or use -o nobarrier on
> ext4, the chance of significant file system damage if you have a power
> failure, since without the barrier, the file system doesn't wait for
> disk to acknowledge that the data has hit the barrier. The problem is
> that if you are using a barrier operation, you're not going to be able
> to get more than about 30-50 non-trivial[1] fsync's per second on a
> standard HDD; barriers are inherently slow.
>
I think that currently the fsyncs have a double meaning: they are used
to make a filesystem operation happen before another filesystem
operation, and to make a filesystem operation happen before a network
operation. I don't think the second case can be speeded up (there can be
a distributed transaction involved) but the first could probably be
speeded up, but I'm thinking how...
Do you think nobarrier + data=journal would provide the same guarantees
of barrier and almost the same performances of nobarrier (for random I/O)?
Hmm maybe you need the barriers enabled to make even data=journal work
reliably?
But then there should be a mount option (barriersonlyjournal?) so that
barriers are only generated every so many seconds and only for
committing a big transaction to the journal, while applications' fsyncs
would be made with nobarriers.
This should provide the benefits I mentioned, for disk-to-disk
sequentiality (not disk-to-network), shouldn't it?
next prev parent reply other threads:[~2011-01-22 1:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 0:13 Severe slowdown caused by jbd2 process Jon Leighton
2011-01-21 1:31 ` Josef Bacik
[not found] ` <1295601083.5799.3.camel@tybalt>
2011-01-21 12:59 ` Josef Bacik
2011-01-21 14:03 ` Josef Bacik
2011-01-21 14:28 ` Jon Leighton
2011-01-21 14:31 ` Josef Bacik
2011-01-21 23:56 ` Ted Ts'o
2011-01-22 1:11 ` torn5 [this message]
2011-01-22 1:34 ` Ted Ts'o
2011-01-22 16:21 ` torn5
2011-01-22 19:37 ` Theodore Tso
2011-01-22 23:22 ` torn5
2011-01-23 5:17 ` Ted Ts'o
2011-01-23 18:43 ` torn5
2011-01-24 20:16 ` Ted Ts'o
2011-01-22 13:05 ` Ric Wheeler
2011-01-24 20:41 ` Darrick J. Wong
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=4D3A2EC6.3020700@shiftmail.org \
--to=torn5@shiftmail.org \
--cc=j@jonathanleighton.com \
--cc=josef@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).