Date: Fri, 30 May 2003 09:21:11 -0700
From: Andrew Morton <akpm@digeo.com>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: jacobs@penguin.theopalgroup.com, linux-kernel@vger.kernel.org
Subject: Re: Ext3 meta-data performance
Message-Id: <20030530092111.5bdadf5c.akpm@digeo.com>
In-Reply-To: <3ED772F5.8060100@cyberone.com.au>
References: <Pine.LNX.4.44.0305290923330.11990-100000@penguin.theopalgroup.com>
	<3ED772F5.8060100@cyberone.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Nick Piggin <piggin@cyberone.com.au> wrote:
>
> >
>  >I have some more time to experiment, so please let me know if there is
>  >anything else you think I should try.
>  >
>  Andrew might be able to suggest some worthwhile tests, if nothing
>  else, try mounting your filesystems as ext2, so you can get a
>  baseline figure.

So the workload is a `cp -Rl' of a 500,000 file tree?

Vast amounts of metadata.  ext2 will fly through that.  Poor old ext3 has
to write everything twice, and has to keep on doing seek-intensive
checkpointing when the journal fills.

When we get Andreas's "dont bother reading empty inode blocks" speedup
going it will help both filesystems quite a bit.

Increasing the journal size _may_ help.  `tune2fs -J size=400', or `mke2fs
-j J size=400'.

The Orlov allocator will help this workload significantly, but you have to
give it time to settle in: it uses different decisions for the placement of
directories on disk.  If the source directory of the copy was created by a
2.4 filesystem then we won't get any of that benefit.


-
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/