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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.