linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	jack@suse.cz
Subject: Re: [PATCH 0/3] Ext3 latency improvement patches
Date: Fri, 27 Mar 2009 17:03:38 -0400	[thread overview]
Message-ID: <1238187818.27455.217.camel@think.oraclecorp.com> (raw)
In-Reply-To: <1238187031.27455.212.camel@think.oraclecorp.com>

On Fri, 2009-03-27 at 16:50 -0400, Chris Mason wrote:
> On Fri, 2009-03-27 at 16:24 -0400, Theodore Ts'o wrote:
> > The following patches have been posted as providing at least some
> > partial improvement to the ext3 latency problem that has been
> > discussed on the 2.6.29 mongo-LKML-thread-that-would-not-die.
> 
> Ric had asked me about a test program that would show the worst case
> ext3 behavior.  So I've modified your ext3 program a little.  It now
> creates a 8G file and forks off another proc to do random IO to that
> file.
> 
> Then it runs one fsync every 4 seconds and times how long they take.
> After the program has been running for 60 seconds, it tries to stop.
> 
> On my sata drive with barriers on, even btrfs and xfs saw some
> multi-second fsyncs, but ext3 came in at 414s for a single fsync.
> 
> Warning: don't run this on a laptop drive, you'll still be waiting for
> it next year.  This is probably full of little errors, I cut it together
> pretty quickly.
> 

My understanding of ext4 delalloc is that once blocks are allocated to
file, we go back to data=ordered.  

Ext4 is going pretty slowly for this fsync test (slower than ext3), it
looks like we're going for a very long time in
jbd2_journal_commit_transaction -> write_cache_pages.

-chris



  reply	other threads:[~2009-03-27 21:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 20:24 [PATCH 0/3] Ext3 latency improvement patches Theodore Ts'o
2009-03-27 20:24 ` [PATCH 1/3] block_write_full_page: Use synchronous writes for WBC_SYNC_ALL writebacks Theodore Ts'o
2009-03-27 20:24   ` [PATCH 2/3] ext3: Use WRITE_SYNC for commits which are caused by fsync() Theodore Ts'o
2009-03-27 20:24     ` [PATCH 3/3] ext3: Avoid starting a transaction in writepage when not necessary Theodore Ts'o
2009-03-27 22:23       ` Jan Kara
2009-03-27 23:03         ` Theodore Tso
2009-03-30 13:22           ` Jan Kara
2009-03-27 22:20     ` [PATCH 2/3] ext3: Use WRITE_SYNC for commits which are caused by fsync() Jan Kara
2009-03-27 20:55   ` [PATCH 1/3] block_write_full_page: Use synchronous writes for WBC_SYNC_ALL writebacks Jan Kara
2009-04-07  6:21   ` Andrew Morton
2009-04-07  6:50     ` Andrew Morton
2009-04-07  7:08       ` Jens Axboe
2009-04-07  7:17         ` Jens Axboe
2009-04-07  8:16           ` Jens Axboe
2009-04-07  7:23         ` Andrew Morton
2009-04-07  7:57           ` Jens Axboe
2009-04-07 19:09             ` Theodore Tso
2009-04-07 19:32               ` Jens Axboe
2009-04-07 21:44                 ` Theodore Tso
2009-04-07 22:19                   ` [PATCH] block_write_full_page: switch synchronous writes to use WRITE_SYNC_PLUG Theodore Tso
2009-04-07 23:09                     ` Andrew Morton
2009-04-07 23:46                       ` Theodore Tso
2009-04-08  8:08                       ` Jens Axboe
2009-04-08 22:34                         ` Andrew Morton
2009-04-09 17:59                           ` Jens Axboe
2009-04-08  6:00                     ` Jens Axboe
2009-04-08 15:26                       ` Theodore Tso
2009-04-08  5:58                   ` [PATCH 1/3] block_write_full_page: Use synchronous writes for WBC_SYNC_ALL writebacks Jens Axboe
2009-04-08 15:25                     ` Theodore Tso
2009-04-07 14:19           ` Theodore Tso
2009-03-27 20:50 ` [PATCH 0/3] Ext3 latency improvement patches Chris Mason
2009-03-27 21:03   ` Chris Mason [this message]
2009-03-27 21:19     ` Jan Kara
2009-03-27 21:30     ` Theodore Tso
2009-03-27 21:54       ` Jan Kara
2009-03-27 23:09         ` Theodore Tso
2009-03-28  0:14           ` Jeff Garzik
2009-03-28  0:24             ` David Rees
2009-03-30 14:16               ` Ric Wheeler
2009-03-30 11:23       ` Aneesh Kumar K.V
     [not found]       ` <20090330112330.GA11357@skywalker>
2009-03-30 11:44         ` Chris Mason

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=1238187818.27455.217.camel@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    --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).