Announcement

Collapse
No announcement yet.

Reiser4 Benchmarked On Linux 3.5

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by curaga View Post
    ..and the fact that it uses a fuckhuge amount of ram to work properly. 1gb minimum was it? Dedicated, only for ZFS at that.
    Here is his guide:
    https://github.com/ryao/zfs-overlay/...er/zfs-install
    With the option zfs_arc_max for the zfs module, you can restrict the amount of memory used for the cache.

    The big problem is with ZFS as rootfs on Linux, you cannot set this parameter as kernel commandline because the module cannot be included into the kernel (licence issues).

    It should not be less than 512MB and a good value is 1/4 of available memory.
    http://wiki.gentoo.org/wiki/ZFS#Tweak

    Comment


    • #17
      Indeed. I'm *not* going to waste min(1/4, 512mb) of my RAM for some FS cache that can't be dropped.

      Comment


      • #18
        Well guys in my opinion I have to say that I am impressed of the way a filesystem out of the kernel tree, maintained for years only by one person in his free time beats out the GREAT NEW btrfs at many tests and the only test showed significant weakness was the multi threaded IO tester which may indicate just a bug that is missed from the hobbyist maintainer it has.
        Also it shows significant performance upgrade from the classic ReiserFS and it is very significant that sometimes it beats out all other FSes!
        For me it deserves to enter the mainline tree as well as getting more attention by developers. I used to use ReiserFS in the past at SuSE distros and it never let me down back then.
        My comments about all tested FSes:
        -EXT4: The most complete package for now.
        -Btrfs: Much more said, much less we see in action.
        -XFS: Still on the podium!
        -ReiserFS: Obsolete.
        -Reiser4 : An unexpected good performer!

        I am sorry Michael but I have to disagree with you at the conclusion of the article about Btrfs and Reiser4.
        Btrfs still has not proved itself all those years being in heavy development furthermore in the way it is advertized as an FS for SSDs. Its grandpa XFS many times proves to be faster on both SSDs and HDDs.
        Reiser4 on the other hand was an unknown quantity but today we took a taste of its performance and was not bad at all!

        Comment


        • #19
          i would rather see more development in Reiser4 than on BTRFS.

          Comment


          • #20
            strange benchmark logs. where is the command used for creating reiser4?
            if during creation the flavour cryptcompress was chosen, maybe even with always-compress, it's an unfair comparison. this would explain why it performs so poorly in multithreading: all processors (especially on intel the "cores") are occupied with number-crunching for the compression.
            or did the other filesystems have some compression feature turned on too? on ssd compression might be a bad idea anyway...

            Comment


            • #21
              FTRFS

              Are there any updates to the "Fractal Tree FS" , based on TokuDB ?
              One of TokuDB's employees gave a working presentation of FTRFS on some bigdata summit in July 2012. Any updates since then ?

              Comment


              • #22
                Originally posted by mayankleoboy1 View Post
                Is Reiser4 the "Brain fuck scheduler" of file systems ?
                It has merits, and can be developed further to beat a lot of mainline FS's. But it wont be _ever_ introduced in the mainline kernel. For reasons that some critics say are biased against the _developer_ , rather than the technical merit of the code itself.
                Reiser4 not being in the Kernel is all about the code quality, which is crap and the developer, he was an ass even to Linus. Please do not compare the awesomeness of BFS to the shittyness of ReiserFS.

                Comment


                • #23
                  Originally posted by curaga View Post
                  ..and the fact that it uses a fuckhuge amount of ram to work properly. 1gb minimum was it? Dedicated, only for ZFS at that.
                  ZFS will give RAM back to the system if your system is under memory pressure. The limit on ARC is the maximum that it will permit itself to use. It by no means prevents your programs from using that memory should they need it.

                  Originally posted by disi View Post
                  Here is his guide:
                  https://github.com/ryao/zfs-overlay/...er/zfs-install
                  With the option zfs_arc_max for the zfs module, you can restrict the amount of memory used for the cache.

                  The big problem is with ZFS as rootfs on Linux, you cannot set this parameter as kernel commandline because the module cannot be included into the kernel (licence issues).

                  It should not be less than 512MB and a good value is 1/4 of available memory.
                  http://wiki.gentoo.org/wiki/ZFS#Tweak
                  I need to find time to rewrite that wiki page. That tip is completely wrong. Being less than 512MB is fine. On 32-bit ARM systems, people have set zfs_arc_max to 40MB at my suggestion. A good value is generally leaving it alone because the default of 1/2 works well. That is unless you are on a 32-bit system, where some tuning is necessary for now.

                  Also, ZFS can be included in the kernel. You just cannot redistribute a kernel binary that contains ZFS support. Here is a link to a slightly dated guide that says how to do this:

                  https://mthode.org/gentoo-hardened-z...-dm-cryptluks/

                  Originally posted by curaga View Post
                  Indeed. I'm *not* going to waste min(1/4, 512mb) of my RAM for some FS cache that can't be dropped.
                  It actually can. Just do echo 3 > /proc/sys/vm/drop_caches.

                  Anyway, feel free to continue using an inferior page replacement algorithm and endure the lags that occur because your cache is wiped whenever a sudden temporary change in your workload doesn't use anything already in the cache. I will not stop you.
                  Last edited by ryao; 10-18-2012, 06:44 AM.

                  Comment


                  • #24
                    Originally posted by Rallos Zek View Post
                    Reiser4 not being in the Kernel is all about the code quality, which is crap and the developer, he was an ass even to Linus. Please do not compare the awesomeness of BFS to the shittyness of ReiserFS.
                    How do you get to the conclusion that code quality is crap and what do you mean exactly by that term??
                    Furthermore performance comparison does not show any shittyness of Reiser4 or even more any awesomeness of Btrfs to my eyes...
                    Except only if you mean some advanced features btrfs demonstrates like cloning and stuff which for the average user I think are close to meaningless...

                    Comment

                    Working...
                    X