Re: [reiserfs-list] [PATCH] 2.4.10 improved reiserfs a lot, but

Chris Mason (mason@suse.com)
Mon, 24 Sep 2001 10:46:09 -0400


On Monday, September 24, 2001 10:09:59 PM +0800 Beau Kuiper
<kuib-kl@ljbc.wa.edu.au> wrote:

> Hi all again,
>
> I have updated my last set of patches for reiserfs to run on the 2.4.10
> kernel.
>
> The new set of patches create a new method to do kupdated syncs. On
> filesystems that do no support this new method, the regular write_super
> method is used. Then reiserfs on kupdated super_sync, simply calls the
> flush_old_commits code with immediate mode off.
>

Ok, I think the patch is missing ;-)

What we need to do now is look more closely at why the performance
increases. There are a few possibilities:

1) larger transactions due to less frequent commits.

2) More efficient metadata writes due to less frequent calls to
reiserfs_journal_kupdate

3) Less time spent flushing direct->indirect targets due to less frequent
commits.

The good news is we can easily separate these. Start by running
debugreiserfs -j /dev/xxx > /tmp/foo

This prints out the transactions still in the log. You are looking for
j_len, which is the length of each transaction. The closer this is to ~900
or so, the more efficient the log is.

Q1) Does your patch increase the average length of the transactions?

Q2) Run the tests again with -o notail (including on pure 2.4.10). Does
the performance gain go down relative to pure 2.4.10?

If Q1 is true, we might be able to tune /proc/sys/vm/bdflush to have
similar benefits.

If Q2 is true, we need to tune the way direct->indirect targets get flushed
(this probably neesd to be tuned regardless).

If neither is true, it is probably the less frequent calls to
reiserfs_journal_kupdate, also tunable through the bdflush params.

I'm not saying we don't need your patch, but I'd like to find out for sure
why it is helping.

Thanks,
Chris

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