lkml.org 
[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: patch: reiserfs for 2.3.49
Chris Evans wrote:

>
> Thanks for the detailled post on the status. One piece of information
> was missing though, which I think might be of interest to readers of this
> list; how fast is this beast ;-)

We don't yet have a set of valid benchmarks. I can generally say that I don't
have confidence in the benchmark performance of this code, there are too many
tweaks not yet done, and our goal for Monday is a port to 2.3.51 that does not
crash. I hope Linus will put this port in as an experimental filesystem, and
then a bit later we'll be able to tell him the performance merits making it a
more than experimental use FS.

We have some tail packing algorithms new to 2.3 that are worse in some
benchmarks than the 2.2 code. This will be fixed after more time for tweaking
(or going back to the old algorithms) passes.

It has long been an architectural weakness of ReiserFS that we allocate block
numbers to buffers as we need each buffer. We knew that we should cure this by
doing either pre-allocation of blocknrs as ext2 does (meaning allocate many
blocks at a time, and then keep them reserved for that file until file close),
or allocating block numbers on dirty buffer/page flush as XFS does. It is for
sure the case that our current practice of allocating blocks as we need new
buffers to write into is a bad architecture. Yura wrote some pre-allocation code
that improved our performance by as much as 4x in some benchmarks, but I
discouraged it because I prefer allocate on flush. This decision is hurting us
at the moment. Pre-allocation is much easier to code (and already written by
Yura for an older version), allocate on flush is the right answer long-term.
Zam has been working on allocate on flush for about 6 weeks, but it is not ready
yet. I think we will have Yura throw in his pre-allocation code until the
allocate on flush code is completed. I hypothesize (not enough data yet to
consider it an observation) that having good SMP in VFS makes writes more evenly
interleaved using our current block allocation bad architecture, and more evenly
interleaved is bad for performance.

There is also unfinished work to decrease the lock granularity throughout
reiserfs. We don't yet know how much effect that has, but it surely has some.

So, in summary, 2.3.51 ~Monday, not sure how many days for pre-allocation but
not a lot. We really need that allocate on flush code and a few more tweaks in
various places before we can start smiling at our benchmarks and taking weekends
off again, but until then I hope we will at least be admissible as an
experimental FS. Everyone is working quite hard.

Hans
--
You can get ReiserFS at http://devlinux.org/namesys, and customizations and
industrial grade support at reiser@idiom.com.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.164 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site