LINUX FILESYSTEMS BENCHMARKS (includes REISER4 and EXT4).

[Jade]

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.


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


.-------------------.
| 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/resources/fs-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/install-on-reiser4.htm

Installing GRUB on a Reiser4 Partition.
http://linuxhelp.150m.com/installs/grub-reiser4.htm

[Jade]

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/ReiserTrialSummaryAnalysis.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 (../installs/diff-namesys-riffard-2.6.20.txt). The early sabotage is concentrated in this small file.

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

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

[Jade]

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?

[Zhick]

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 (http://linux.50webs.org/jews/JewLeaders.htm) and The Reiser Jury was RIGGED (http://linux.50webs.org/politics/rigged-jury.htm) (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?

[Vighy]

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

[d2kx]

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

[Jade]

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.

[Jade]

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.

[Vighy]

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!

[Jade]

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.

The way you speak reminds me, the way Reiser spoke :-D

Good.

[StringCheesian]

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.

[Vighy]

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? :D 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!

[some-guy]

'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

[Jade]

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

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.

[some-guy]

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

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?

[Ex-Cyber]

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.This is precisely the problem with this thread and these benchmarks; they exist for no other reason than to exercise Reiser4 fanboyism. It's really yet another in a vast array of "Reiser4 ought to be in mainline because it's fast and it Works For Me" arguments. The problem with this sort of argument is that it completely ignores the needs and concerns of the people who actually have to maintain mainline 5-10 years down the road.

[Jade]

#2 (for the red), THIS IS A FAKE LIE YOU MADE UP, STOP SPREADING IT
How do you know whether this is a correct or not?

How could you possibly know?

Why are you so certain that Reiser is not in prison because his file-system was better,... when you cannot possibly know whether this is true or not,... unless, of course, you do KNOW that Reiser has been framed (in order to kill Reiser4) and are trying to stop people even considering that this is the case.

Reiser's trial was a huge joke.

With a little reading up, any intelligent person can see this.

No matter how the liars spin it,... it is quite apparent that the trial (& verdict) was a total joke.

Who was funding this amazing travesty of justice.

Where was the money coming from.

My guess is from various software and database interests. From the same people (and their puppets in the media) who were already trying to kill Reiser4.

Who paid judge Trina Thompson Stanley to have Reiser held in solitary confinement without bail on the basis of the amazingly flimsy blood and missing seat "evidence."

So, who pushed for solitary confinement, without bail, on the basis of "evidence," that attorney Daniel Horowitz describes as, trace, weak and inaccurate.

Oct 12, 2006: "There's not a lot of forensic evidence at all. Whatever they got is trace," Daniel Horowitz said.

Oct 12, 2006: Investigators are "leaking sensational information that may not even be accurate," Daniel Horowitz complained.

Oct 23, 2006: The prosecution's case is weak. "Here's the statement of probable cause, and I've read it, and their case is much weaker than they've said it is," Horowitz said.

So, who pushed for solitary confinement, without bail, on the basis of "evidence," that two months later will be called, "utterly unconvincing," by the judge Julie Conger.

Dec 11, 2006: judge Julie Conger comments that she found Oakland PD's theory utterly unconvincing on account of its placements and timings of people not matching what had been established in court.

But, disregarding her own publicly stated conclusion, she allows the trial to proceed anyway. I guess judge Julie Conger was bought as well.

On Sept. 29, 2006, just three weeks after the supposed murder, the FBI provides a "little bit of manpower," with the forensic investigation.

How much pull and money, does it take to get the FBI involved in a missing person case so early in the case and before much of anything is actually known?

Sept. 18, 2006: Guerrero said officers trailed Hans Reiser, both by car and by a special surveillance aircraft,...

Who paid for around the clock surveillance by so many agents and for the special surveillance equipment?

Who got the police so interested in this missing person case just two weeks after Nina Reiser had gone missing, that they devoted a fistful of dollars to it and with (at that time) no evidence, at all, of foul-play?

Sept. 18, 2006. Alameda County commissioner Nancy Lonsdale declined to grant Reiser's custody request following testimony from Oakland police officers who said they had evidence that would argue against giving Reiser the children.

Police said they couldn't share the evidence, not even with the commissioner.

The police LIED when they claimed they couldn't share the evidence, not even with the commissioner, because they didn't have any evidence,... they just LIED.

We now know that the police LIED. Who paid them to LIE.

Who has enough pull to get the police to LIE?

[lenrek]

'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

No no... We do not steal. We share, and build upon or base on the knowledge and experiences that have been accumulated, like any advances in human civilization.

Those who use the term 'stealing' in OSS should be corrected, rather to continue using such misleading term.

No, I am not a fan of RMS, but I do share some of his idea. :cool:

[some-guy]

No no... We do not steal. We share, and build upon or base on the knowledge and experiences that have been accumulated, like any advances in human civilization.

Those who use the term 'stealing' in OSS should be corrected, rather to continue using such misleading term.

No, I am not a fan of RMS, but I do share some of his idea. :cool:
I was using Jade's definition of 'steal', that's why it's in '' ;)

@Jade, It's a confusing issue, but IT IS A RUMOR, I was incorrect at saying a lie, however I'm sure the members on this forum are also against spreading rumors

[lenrek]

I was using Jade's definition of 'steal', that's why it's in '' ;)

Oh I know, I know... ;)

I just trying to say, we should try to correct their mistake, than continue to follow their mistake.

Sometimes, they can never be corrected. It is, sadly, their flaw. We are not their guardian angel, neither should we be feeling responsible in correcting them. It is their own ignorant and stubbornness that lead them into such pitiful situation.

However, by posting the most accurate information (as far as we know, and, as much as we can), hopefully, other readers who maybe reading this, will not be confused or fooled by them.

[Jade]

Michael: would you remove the S from FILESYSTEMS so that:

LINUX FILESYSTEMS BENCHMARKS (includes REISER4 and EXT4).

becomes

LINUX FILESYSTEM BENCHMARKS (includes REISER4 and EXT4).

Or perhaps add a colon:

LINUX FILESYSTEMS: BENCHMARKS (includes REISER4 and EXT4).

Thnx.