Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: LINUX FILESYSTEMS BENCHMARKS (includes REISER4 and EXT4).

  1. #1
    Join Date
    Sep 2006
    Posts
    353

    Default 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 at 08:22 PM.

  2. #2
    Join Date
    Sep 2006
    Posts
    353

    Default

    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 at 08:26 PM.

  3. #3
    Join Date
    Sep 2006
    Posts
    353

    Default

    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?

  4. #4
    Join Date
    May 2008
    Location
    Germany/NRW
    Posts
    510

    Default

    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?

  5. #5
    Join Date
    Dec 2007
    Location
    /dev/hell
    Posts
    297

    Default

    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 at 11:52 AM. Reason: typo

  6. #6
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,093

    Default

    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).

  7. #7
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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.

  8. #8
    Join Date
    Sep 2006
    Posts
    353

    Default

    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.

  9. #9
    Join Date
    Dec 2007
    Location
    /dev/hell
    Posts
    297

    Default

    Quote 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!

  10. #10
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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.

    Quote 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 at 09:59 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •