Re: [reiserfs-list] [PATCH] 2.4.10 improved reiserfs a lot, but could still be better

[Chris Mason <mason@suse.com>]

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