Re: Journal Filesystem Comparison on Netbench

[Andi Kleen <ak@suse.de>]

Hans Reiser <reiser@namesys.com> writes:

> That said, it does not surprise me that our locking is coarser than other
> filesystems, and we will be fixing that in version 4.  Unfortunately we don't
> have the hardware to replicate your results.

It does not really look like a locking problem. If you look at the profiling
logs it is pretty clear that the problem is the algorithm used in 
bitmap.c:find_forward. find_forward and reiserfs_in_journal 
(called by find_forward)
are by most the biggest CPU users in file system space, and 
reiserfs_in_journal is called over 30 million times, far more often than
any other function. On looking at it it is pretty clear why it is slow;
the algorithm is just stupid. It also runs under the BKL, which explains 
the long locking times. Fix that function and it'll look much better.
i.e. one way would be to keep a shadow map of all bitmaps that has all
journaled blocks set also, to quickly skip them for the common case.

-Andi