Date: Wed, 16 May 2007 11:25:15 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Chris Mason <chris.mason@oracle.com>
Cc: Chuck Ebbert <cebbert@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: filesystem benchmarking fun
Message-Id: <20070516112515.b6f247b2.akpm@linux-foundation.org>
In-Reply-To: <20070516171156.GY26766@think.oraclecorp.com>
References: <20070516144205.GV26766@think.oraclecorp.com>
	<464B2AC2.10206@redhat.com>
	<20070516171156.GY26766@think.oraclecorp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1507
Lines: 32

On Wed, 16 May 2007 13:11:56 -0400
Chris Mason <chris.mason@oracle.com> wrote:

> At least on ext3, it may help to sort the blocks under io for
> flushing...it may not.  A bigger log would definitely help, but I would
> say the mkfs defaults should be reasonable for a workload this simple.
> 
> (data=writeback was used for my ext3 numbers).

When ext3 runs out of journal space it needs to sync lots of metadata out
to the fs so that its space in the journal can be reclaimed.  That metadata
is of course splattered all over the place so it's seekstorm time.

The filesystem does take some care to place the metadata blocks "close" to
the data blocks.  But of course if we're writing all the pagecache and then
we later separately go back and write the metadata then that would screw
things up.

I put some code in there which will place indirect blocks under I/O at the
same time as their data blocks, so everything _should_ go out in a nice
slurp (see write_boundary_block()).  The first thing to do here is to check
that write_boundary_block() didn't get broken.

If that's still working then the problem will _probably_ be directory
writeout.  Possibly inodes, but they should be well-laid-out.

Were you using dir_index?  That might be screwing things up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/