Messages in this thread | | | Date | Sat, 11 Mar 2000 22:02:56 +0300 | From | Hans Reiser <> | Subject | Re: 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/
| |