Announcement

Collapse
No announcement yet.

LINUX FILESYSTEMS BENCHMARKS (includes REISER4 and EXT4).

Collapse
This topic is closed.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LINUX FILESYSTEMS BENCHMARKS (includes REISER4 and EXT4).

    LINUX FILESYSTEMS BENCHMARKS
    (includes Reiser4 and Ext4)


    http://linuxhelp.150m.com/
    http://linux.50webs.org/

    RESULT: With compression, REISER4, absolutely SMASHED the other filesystems.

    No other filesystem came close (not even remotely close).

    Using REISER4 (gzip), rather than EXT2/3/4, saves you a truly amazing 816 - 213 = 603 MB (a 74% saving in disk space), and this, with little, or no, loss of performance when storing 655 MB of raw data. In fact, substantial performance increases were achieved in the bonnie++ benchmarks.

    We use the following filesystems:

    REISER4 gzip: Reiser4 using transparent gzip compression.
    REISER4 lzo: Reiser4 using transparent lzo compression.
    REISER4 Standard Reiser4 (with extents)
    EXT4 default Standard ext4.
    EXT4 extents ext4 with extents.
    NTFS3g Szabolcs Szakacsits' NTFS user-space driver.
    NTFS NTFS with Windows XP driver.

    Disk Usage in megabytes. Time in seconds. SMALLER is better.

    Code:
    .-------------------------------------------------.
    |File         |Disk |Copy |Copy |Tar  |Unzip| Del |
    |System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
    |Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
    .-------------------------------------------------.
    |REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
    |REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
    |REISER4 tails| 673 | 148 |  63 |  78 |  33 |  65 |
    |REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
    |NTFS3g       | 772 |1333 |1426 | 585 | 767 | 194 |
    |NTFS         | 779 | 781 | 173 |   X |   X |   X |
    |REISER3      | 793 | 184 |  98 |  85 |  63 |  22 |
    |XFS          | 799 | 220 | 173 | 119 |  90 | 106 |
    |JFS          | 806 | 228 | 202 |  95 |  97 | 127 |
    |EXT4 extents | 806 | 162 |  55 |  69 |  36 |  32 |
    |EXT4 default | 816 | 174 |  70 |  74 |  42 |  50 |
    |EXT3         | 816 | 182 |  74 |  73 |  43 |  51 |
    |EXT2         | 816 | 201 |  82 |  73 |  39 |  67 |
    |FAT32        | 988 | 253 | 158 | 118 |  81 |  95 |
    .-------------------------------------------------.
    WHAT THE NUMBERS MEAN:

    The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
    It comprised 3 different copies of the Linux kernel sources.

    Disk Usage: The amount of disk used to store the data.
    Copy 655MB (1): Time taken to copy the data over a partition boundary.
    Copy 655MB (2): Time taken to copy the data within a partition.
    Tar Gzip 655MB: Time taken to Tar and Gzip the data.
    Unzip UnTar 655MB: Time taken to UnGzip and UnTar the data.
    Del 2.5 Gig: Time taken to Delete everything just written (about 2.5 Gig).

    Each test was preformed 5 times and the average value recorded.

    To get a feel for the performance increases that can be achieved by using compression, we look at the total time (in seconds) to run the test:

    bonnie++ -n128:128k:0 (bonnie++ is Version 1.93c)

    Code:
    .-------------------.
    | FILESYSTEM | TIME |
    .-------------------.
    |REISER4 lzo |  1938|
    |REISER4 gzip|  2295|
    |REISER4     |  3462|
    |EXT4        |  4408|
    |EXT2        |  4092|
    |JFS         |  4225|
    |EXT3        |  4421|
    |XFS         |  4625|
    |REISER3     |  6178|
    |FAT32       | 12342|
    |NTFS-3g     |>10414|
    .-------------------.
    The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen in the first test above where compression often does not speed things up. However, more importantly, it does not slow things down much, either.

    http://linuxhelp.150m.com/resources/fs-benchmarks.htm
    http://m.domaindlx.com/LinuxHelp/res...benchmarks.htm

    For more information regarding Reiser4, see these

    REISER4 HOWTOS.

    Some Amazing Filesystem Benchmarks. Which Filesystem is Best?
    http://linuxhelp.150m.com/resources/fs-benchmarks.htm

    Compiling yourself a 2.6.23 Kernel (with Reiser4 support). (2.6.24 Kernel Patch)
    http://linuxhelp.150m.com/installs/compile-kernel.htm

    Installing your favorite Linux Distro on Reiser4.
    http://linuxhelp.150m.com/installs/i...on-reiser4.htm

    Installing GRUB on a Reiser4 Partition.
    http://linuxhelp.150m.com/installs/grub-reiser4.htm
    Last edited by Jade; 06-19-2008, 08:22 PM.

  • #2
    I'm sure Micheal had no problem with the Reiser4 benchmarks as such.

    When dealing with Reiser4, one immediately has to deal with:

    The HANS REISER Murder Trial. Timeline and Analysis.

    http://www.phoronix.com/forums/showthread.php?t=7544
    http://linux.50webs.org/politics/Rei...ryAnalysis.htm and of course,...

    The Linux Kernel Saboteurs.

    Although the Linux kernel saboteurs (a number of so called Linux kernel "developers") have sabotaged many areas of Linux, I will concentrate on their efforts in sabotaging Reiser4.

    As some will have noticed, Reiser4 no longer works as it used to. The recent patches of Andrew Morton, and Riffard Laurent, cause corruption problems (when they work at all). Morton's patches, also reduced Reiser4's functionality, removing, for example, the cryptocompress plugin. Riffard's patches include the cryptocompress plugin, which seems to work, but the patch causes corruption for plain Reiser4.

    You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.

    The parts of Reiser4 they have not touched, still work, but where they have coded, Reiser4 no longer works.

    The fact that Reiser4 worked well, before Hans Reiser's arrest and imprisonment (on what appears to be trumped-up charges) and now doesn't, means that it should be easy to spot the sabotage.

    After digging around in the source code, the evidence of deliberate sabotage is very clear.

    I present some of the evidence (found by comparing Riffard's patch with older Namesys patches) below.

    Update: Namesys has released 2.6.20 and 2.6.21 kernel patches. This has enabled one to completely isolate the differences between Namesys' 2.6.20 patch and Riffard's. The diff file is very small and can be found here. The early sabotage is concentrated in this small file.

    One act of sabotage, is found in reiser4/page_cache.c:

    Code:
    int reiser4_page_io(struct page *page, jnode *node, int rw, gfp_t gfp)
    {
    	struct bio *bio;
    	int result;
    
    	assert("nikita-2094", page != NULL);
    	assert("nikita-2226", PageLocked(page));
    	assert("nikita-2634", node != NULL);
    	assert("nikita-2893", rw == READ || rw == WRITE);
    
    	if (rw) {
    		if (unlikely(page->mapping->host->i_sb->s_flags & MS_RDONLY)) {
    			unlock_page(page);
    			return 0;
    		}
    	}
    
    	bio = page_bio(page, node, rw, gfp);
    	if (!IS_ERR(bio)) {
    		if (rw == WRITE) {
    			SetPageWriteback(page); 
    	Changed to	set_page_writeback(page);
    			unlock_page(page);
    		}
    		reiser4_submit_bio(rw, bio);
    		result = 0;
    	} else {
    		unlock_page(page);
    		result = PTR_ERR(bio);
    	}
    
    	return result;
    }
    where SetPageWriteback has been changed to set_page_writeback.

    This change is hard to spot with SetPageWriteback and set_page_writeback, being very similar in name. This change is almost guaranteed to cause problems, as set_page_writeback is called without calling end_page_writeback(). According to Documentation/filesystems/Locking, this will leave the page itself marked clean but it will be tagged as dirty in the radix tree. This incoherency can lead to all sorts of hard-to-debug problems in the filesystem like having dirty inodes at umount and losing written data. Just as the saboteurs desire, and what we see happening.

    For the rest of the article, see:

    http://linuxhelp.150m.com
    http://linux.50webs.org
    Last edited by Jade; 06-19-2008, 08:26 PM.

    Comment


    • #3
      Actually closing the thread

      http://www.phoronix.com/forums/showthread.php?t=1765

      because of some off-topic remarks seems to set a poor precedent.

      Will you close all threads where an off-topic remark is made?

      Comment


      • #4
        I guess some off-topic-chatting is alright, but the old thread was only about your conspiration theories.

        To stay on topic: I find it hard to believe a site which also has articles like Bush, Blair, Putin, Merkel and many other leaders are all Jews and The Reiser Jury was RIGGED (claiming this is one thing, but the way they "prove" their claim is hillarious. If you want a good laugh hava a look at the article). They are obviously not the most trustworthy source of information (imho, if you love conspiration theories you'll probably happily believe everything they say).

        I'd like to run some benchmarks myself but I'm to lazy to re-partition my hdds to do so. Will the results of the benchmarks be affected when they are run inside a virtual machine (VirtualBox e.g.) on a ext3-partition? The absolute numbers will of course change, but I wonder if the relations between the results will be the same as when run natively?

        Comment


        • #5
          Beautiful numbers... but... ext4 was a bit young.... at that time :-P why not re-running the tests, updated? and what about multi-threaded workload? and so on...

          @zhick you could make tests on loop devices.... it's incredibly handful!

          @jade again, who is the maintainer of that site? I hope it's not you...
          Last edited by Vighy; 06-18-2008, 11:52 AM. Reason: typo

          Comment


          • #6
            Reiser 4 is an interesting filesystem performance wise, but a filesystem which is that unmaintained will not be recommended by anyone, and that is the point why it will not be adopted by Linux I guess. ext4 on the other side will be "good enough", if one can say this, and I am really looking forward to this filesystem.

            Jade's theories are all a bit weird, but I won't say he is wrong, because I don't have enough knowledge to say if it's true or wrong. I think that Jade just shouldn't try to make anyone believe anything, instead he should give his opinion and nothing else (and maybe ask kernel developers what they're thinking about his saboteur theory if he wants some answers).

            Comment


            • #7
              Originally posted by Vighy View Post
              Beautiful numbers... but... ext4 was a bit young.... at that time :-P why not re-running the tests, updated? and what about multi-threaded workload? and so on...
              Yeah,... so now that the inferior (since they are essentially thieves who did not allow Reiser any real credit for his work) Ext4 developers have stolen all of Reiser's ideas,... they are beginning to make up ground in the benchmarks.

              Comment


              • #8
                If you want proof that most of these "conspiracy theories" are correct,... just look at the fact that the people who run this site have disconnected this thread from the main page,... as per usual.

                Rather than discuss things as adults, the children here restrict the conversation by devious means (like delinking a thread so it does not get coverage) or just plain threats.

                This childish behavior is the caused by the fear that intelligent people will see that many of the so-called "conspiracy theories" are very much correct. If those here, did not fear this, they would not subtly censor and threaten.

                Comment


                • #9
                  Originally posted by Jade View Post
                  If you want proof that most of these "conspiracy theories" are correct,... just look at the fact that the people who run this site have disconnected this thread from the main page,... as per usual.

                  Rather than discuss things as adults, the children here restrict the conversation by devious means (like delinking a thread so it does not get coverage) or just plain threats.

                  This childish behavior is the caused by the fear that intelligent people will see that many of the so-called "conspiracy theories" are very much correct. If those here, did not fear this, they would not subtly censor and threaten.
                  The way you speak reminds me, the way Reiser spoke :-D

                  But try to face the problem: these benchmarks are out to date, since they refer to a 2.6.13 kernel, and now we are at 2.6.26...
                  this means it passed much time, and ext4 could have improved even without stealing ideas from reiser4.
                  Indeed Reiser was not the only intelligent guy, and his solutions were not the only good ones!!!

                  I would like to see new benchmarks, and in different test cases. I'm not deviating the thread!

                  What's for sure is that Reiser now cannot maintain his FS, and even if i like ReiserFS so much (it's the only one I use), I think (in a future) I will migrate to JFS.
                  If reiser will come out of prison, and will solve the pending issues with reiser4 (coding style, and so on), i will be happy to test it, and if good to adopt it.
                  Otherwise JFS, will remain my choice for the future.

                  As you can read, I didn't speak about jews, or anything else (even if your nazi-links are horrible!) and I'm not an ext4 supporter!

                  Comment


                  • #10
                    Originally posted by Vighy View Post
                    But try to face the problem: these benchmarks are out to date, since they refer to a 2.6.13 kernel, and now we are at 2.6.26...
                    Try to face the problem: You can't read/didn't bother to read the article.

                    You would look more intelligent (and less like some slimy critter who lies by omission) if you actually read the article.

                    The linux-2.6.20-mm1 kernel is used in the benchmarks (the 2.6.13 kernel is used to show how Reiser4 has got worse under the non-Reiser developers). The reiser4 code has remained almost unchanged for years now, so 2.6.20 is more than adequate.

                    Originally posted by Vighy View Post
                    The way you speak reminds me, the way Reiser spoke :-D
                    Good.
                    Last edited by Jade; 06-19-2008, 09:59 AM.

                    Comment


                    • #11
                      Jade, there seems to have been a misunderstanding.

                      Those benchmarks are meaningful to you and Vighy for different reasons:
                      You are interested in demonstrating Reiser4's superiority and supporting your allegation that it has been sabotaged. For that purpose, perhaps 2.6.20 is "more than adequate" in that it at least shows a decline.

                      Vighy, on the other hand, is (like myself) simply curious to see how various filesystems compare in benchmarks, due to some enthusiasm or interest in Linux, filesystem performance, or all of the above. For that purpose, 2.6.20 and 2.6.13 are both ancient history.
                      Last edited by StringCheesian; 06-19-2008, 12:36 PM.

                      Comment


                      • #12
                        Originally posted by StringCheesian View Post
                        Jade, there seems to have been a misunderstanding.

                        Those benchmarks are meaningful to you and Vighy for different reasons:
                        You are interested in demonstrating Reiser4's superiority and supporting your allegation that it has been sabotaged. For that purpose, perhaps 2.6.20 is "more than adequate" in that it at least shows a decline.

                        Vighy, on the other hand, is (like myself) simply curious to see how various filesystems compare in benchmarks, due to some enthusiasm or interest in Linux, filesystem performance, or all of the above. For that purpose, 2.6.20 and 2.6.13 are both ancient history.
                        You got it!! 2.6.20 is of more than 1 year ago (february 2007) and now is june 2008.... i think the difference is relevant (for me! :-))

                        @jade : I must admit I read all the article and in many benchmarks reiser4 from morton sources (2.6.20) performed much better than reiser original patch (2.6.13)... so I don't agree when you speak about a performance loss due to "sabotage".

                        and jade what about the different kind of workload? like multi-threaded apps: gzip and others are not multi-threaded...

                        for me the thread is finished: until you will provide new benchmarks, there's nothing more to say.
                        I will still prefer JFS upon an unmaintained file-system. (I mean reiser4, not reiserfs)

                        And don't tell me that Reiser is in prison because his file-system was better... I would not stop laughing for a month!
                        Last edited by Vighy; 06-19-2008, 02:46 PM. Reason: missed reference/typo

                        Comment


                        • #13
                          'Stealing' ideas, isn't that what all distros do?
                          If you don't want anything to be 'stolen' you make it proprietary.
                          'Stealing' is what OSS is about, taking other people's work, and improving it

                          Comment


                          • #14
                            Originally posted by StringCheesian View Post
                            2.6.20 and 2.6.13 are both ancient history.
                            Are you brain dead or something,... which part of "the Reiser4 code has essentially not changed for years" didn't you understand.

                            The Reiser4 code for 2.6.20 is (essentially) the same as for 2.6.26.

                            Do a recursive diff.

                            If there are changes (like Reiser4 doesn't work any more) then they are most likely due to changes by kernel people coding outside of the Reiser4 code,... not due to changes in Reiser4 (coding outside Reiser4 could still include sabotage,... by changing the general environment in ways harmful to Reiser4's performance).

                            Originally posted by Vighy View Post
                            And don't tell me that Reiser is in prison because his file-system was better... I would not stop laughing for a month!
                            Reiser is in prison because his file-system was better... End of story.
                            Last edited by Jade; 06-19-2008, 08:38 PM.

                            Comment


                            • #15
                              Originally posted by Jade View Post
                              Are you brain dead or something,... which part of "the Reiser4 code has essentially not changed for years" didn't you understand.

                              The Reiser4 code for 2.6.20 is (essentially) the same as for 2.6.26.

                              Do a recursive diff.
                              Everyone understood it, ext4 has changed so a proper benchmark would used 2.6.26
                              Originally posted by Jade View Post
                              If there are changes (like Reiser4 doesn't work any more) then they are most likely due to changes by kernel people coding outside of the Reiser4 code,... not due to changes in Reiser4 (coding outside Reiser4 could still include sabotage,... by changing the general environment in ways harmful to Reiser4's performance).


                              Reiser is in prison because his file-system was better... End of story.
                              #1, Reiser has to keep up with the kernel NOT the other way around

                              #2 (for the red), THIS IS A FAKE LIE YOU MADE UP, STOP SPREADING IT
                              It's like saying that 'at certain times, both shark attacks and ice cream sales go up' so does this mean ice cream is responsible for shark attacks?

                              Comment

                              Working...
                              X