[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    You can get ReiserFS at, and customizations and
    industrial grade support at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.021 / U:29.584 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site