Linux FILESYSTEM BENCHMARKS (includes Reiser4).

[Jade]

LINUX FILESYSTEM 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

[janl]

Do you just keep posting this same stuff over and over? I'm pretty sure I've seen this same post/thread by you at least twice before.

[Ex-Cyber]

Do you just keep posting this same stuff over and over? I'm pretty sure I've seen this same post/thread by you at least twice before.

Not just reposting stuff, but otherwise yes.

As long as I'm posting, I may as well point this out (again)

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

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

[...]

|REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
|REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
|EXT4 extents | 806 | 162 |  55 |  69 |  36 |  32 |

The only benchmark in which "no other filesystem came close" is disk usage. I don't know about everyone else, but this is not that important to me because:

1) My main disk usage problem is that the PC partition scheme is so inflexible, and

2) The files that typically account for most of my disk usage are already compressed or are otherwise unsuited to general-purpose compression algorithms, so putting them on a compressed filesystem would just burn cycles for no benefit.

[Jade]

Do you just keep posting this same stuff over and over? I'm pretty sure I've seen this same post/thread by you at least twice before.

The other thread were locked.

So, not so good for discussion.

Why were they locked?

You may well ask?

I believe it's a conspiracy.

[alec]

ext4 looks really sexy

But can a ext4 filesystem with extents be at least READ from Windows XP install?

[yoshi314]

when i saw this topic on mainpage i thought to myself
"it must have been started by Jade". guess i was right.

then i saw this :

I believe it's a conspiracy.

now i've fell off my chair laughing and i can't get up ;]

the "Conspiracist" title is well earned, indeed :]

The files that typically account for most of my disk usage are already compressed or are otherwise unsuited to general-purpose compression algorithms, so putting them on a compressed filesystem would just burn cycles for no benefit.

imagine putting reiserfs with compression on lvm on dm-crypt device... that would really hit performance.

i guess that only reasonable real-life application of compressing read-write filesystem is when the files are not going to be changed frequently. otherwise it might cause more problems than solve.

[Jade]

when i saw this topic on mainpage i thought to myself "it must have been started by Jade". guess i was right.

Yeap. You could have also read the name of the thread starter, which is just below the title.

[Pahanilmanlintu]

Wow, dude. I had no idea ext4 is that hot. ^^

I also thought ext3 is kinda obsolete, but it seems to perform very well too. So i guess having to run fsck often is pretty much its only relevant shortcoming in my use cases.

[Thetargos]

Speaking only from experience...

EXT3 is good-enough for regular computing tasks, robust (hence can be slow) and very well supported across pretty much any distribution.

I'm not sure what are the specific changes in EXT4, but from what I have read about it, it does indeed look like a nice file system, AFAIK it still is missing a number of features that other filesystems do implement, but all in all looks rather good. Especially with extensions.

ReiserFS (3.x). This was my preferred file system for a while, it is indeed very good, fast and well supported, however it is corruption prone and I did get some really nasty cases of data corruption with it (where as I have never had one with EXT3, though I did get my share with EXT2). That is about the only problem I found with Reiser 3 and why I stopped using it.

Reiser4, was (is?) in development for quite a while, and it supposedly addresses many of the shortcomings of Reiser3 (i.e. corruption) and increases its overall performance. Also it was re-engineered from scratch and added much more robust journal support (Reiser3 in full journal mode would drop performance so bad, that EXT3 was much faster), and adds support for quite a lot of extensions.

Now Jade here is convinced that this "miracle of FS" is being sabotaged by pretty much everyone (distros by not including support for it, users for not using it, developers) and has even gone as far as to accuse kernel developers of excluding it on purpose and tampering with its source files (case in point some claims about Andrew Morton tampering with some files). Honestly I don't know, maybe this could be due to the whole deal with Reiser being accused of murder and the trial and whatnot (don't even know if the case has been closed or not, or what), I don't know. Has development stopped or does it continue? Some of these days I'll have to update on these matters

[Jade]

...case in point some claims about Andrew Morton tampering with some files...

This is what someone who knows said. From here: http://www.phoronix.com/forums/showp...5&postcount=45 (showpost.php?p=27495&postcount=45)

Thanks for the links, you should probably also put a link to the original this is based on (the Wired Blog).

Remember that in the country this takes place (the murder trial), it doesn't matter what you think. It doesn't even matter what the jury itself thinks of the person's character or "acting strangely" (atleast it's not supposed to) - what matters is what you can prove.

Guilt must be proven, a person is innocent until proven guilty in the USA. There has been a lot of conjecture and circumstantial evidence, which does not mean proof at all.

As to the "kernel saboteurs", uhhmmmm. I have been a user of reiserfs3 for years and never noticed all these "issues" that people all of a sudden came up with (after Reiser was arrested).

In fact I never was affected by any sort of corruption or whatnot - in 6+ years of using the filesystem (since 2.4.0)!

ResierFS v4 is something I've wanted to try for a while, but it seems as if everytime I've gone to just do it that I've been "blocked" by one thing or another (boot CD lacks support, kernel patch is broken, developer kernel has bugs, etc.).

The problem was not that I couldn't just use a NameSys patch on my own kernel (I used my own kernel anyway), and do a double install to get the main install up on v4, the issue was that the last time I looked the last patch I could find to be easily hacked to use a recent kernel (one I wanted) did not support compression. That is the sole reason for me wanting to migrate from v3 to v4, is the realtime compression (not for space increase, but for performance increase).

What I can say from my experience personally is this:

there were several reiserfs v4 patches in a certain kernel developer's tree (Andrew Morton's tree) that were not immediately apparant to be broken... but they were/are.

An unnecessary kludge was introduced for NO REASON WHAT-SO-EVER, which was the cause of the corruption.

This developer is a very "big-name" person, and I will not tell you of whom I speak (this is not about flames, and I don't know why he did it i.e. a mistake or misunderstanding or what).

Needless to say however, a lot of people use his patches for bleeding-edge features, mainly because he is supposed to be "dependable" and "official".

So of course, eventually it was noticed - this few lines of code that was unecessarily introduced causing the coruption, and when asked he gave the most unbelievable answer.

Then he proceeded to do a rewrite and what appeared as "cover his tracks".

Anyhow that is what happened. Make of it what you will, but it surely was NOT bitrot or anything so simple...

If you want to look at conspiracy theories, look at who the biggest sponsor was originally. There's your answer right there, and probably what they'd do to "get rid" of the filesystem (have the inventor locked away)

BTW I've never understood the obsession about ext2 and ext3. ext2 was the worst filesystem I've used since the old days of UFS, and the only filesystems I've personally had explode were both ext2/ext3.

I think I'll go install onto v4 now and do whatever necessary to get it done (if that means reintegrating compression back into the latest version then so be it). I want to do some benchmarks and stress-testing

Wow, dude. I had no idea ext4 is that hot. ^^

I also thought ext3 is kinda obsolete, but it seems to perform very well too. So i guess having to run fsck often is pretty much its only relevant shortcoming in my use cases.

Why shouldn't ext4 be hot?

ext4 is just a RIP OFF of Reiser4.

Just like ext3 was a RIP OFF of JFS.

http://linux.50webs.org/

http://linuxhelp.150m.com/jews/saboteurs.htm

http://m.domaindlx.com/LinuxHelp/jews/saboteurs.htm