login
Search
REISER4 - THE BEST FILESYSTEM EVER.
You can read more here:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
.-------------------------. | FILESYSTEM | TIME |DISK | | TYPE |(secs)|USAGE| .-------------------------. |REISER4 lzo | 1938 | 278 | |REISER4 gzip| 2295 | 213 | .-------------------------. |REISER4 | 3462 | 692 | |EXT2 | 4092 | 816 | |JFS | 4225 | 806 | |EXT4 | 4408 | 816 | |EXT3 | 4421 | 816 | |XFS | 4625 | 779 | |REISER3 | 6178 | 793 | |FAT32 |12342 | 988 | |NTFS-3g |10414 | 772 | .-------------------------.
Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0). 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 below where compression does not speed things up. However, more importantly, it does not slow things down either.
Column two, Disk Usage: measures the amount of disk used to store 655MB of raw data (which was 3 different copies of the Linux kernel sources).
OR LOOK AT THE FULL RESULTS:
.-------------------------------------------------. |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 | .-------------------------------------------------.
Each test was preformed 5 times and the average value recorded.
Disk Usage: The amount of disk used to store the data (which was 3 different copies of the Linux kernel sources).
The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
Copy 655MB (1): Copy the data over a partition boundary.
Copy 655MB (2): Copy the data within a partition.
Tar Gzip 655MB: Tar and Gzip the data.
Unzip UnTar 655MB: UnGzip and UnTar the data.
Del 2.5 Gig: Delete everything just written (about 2.5 Gig).
Reiser4 saves heaps of space.
I have set up a Reiser4 partition with gzip compression, here is the difference in disk usage of a typical Debian installation on two 10GB partitions, one with Reiser3 and the other with Reiser4.
Partitions 3 and 7 have exactly the same data on them (the typical Debian install).
The partitions are exactly the same size (although df records slightly different sizes).
Partition 3 is Reiser3 -- uses 6.4 GB.
Partition 7 is Reiser4 -- uses 2.6 GB.
So Reiser4 uses 2.6 GB to store the (typical) data that it takes Reiser3 6.4 GB to store (note it would take ext2/3/4 some 6.6 GB to store the same info).
oh please
Oh, the LKML thread was long & trolly enough. Please, if you want to do anything "good" then help to integrate reiser4 into the mainline!
oh please
This thread: http://lkml.org/lkml/2007/4/9/4
And this one: http://lkml.org/lkml/2007/4/6/318
Article on how to compile a kernel
There is a new article on how to compile a kernel (with Reiser4) at:
http://linuxhelp.150m.com/installs/compile-kernel.htm
a better approach
a better approach would be:
wget kernel.org/.../linux-2.6.22.tar.bz2
tar -jxf linux*
cd linux-2.6.22
make menuconfig
make bzImage modules
--- boot ---
please, help to integrate it into the mainline instead!
awesome, been looking for FS
awesome, been looking for FS benchmarks for a long time now. finally some concrete data.
Same as "make oldconfig"?
Does "make menuconfig" provide the same configuration as "make oldconfig" if you always choose the default in "make oldconfig"?
Yes, they are the same.
Yes, they are the same.
Thank you, that's allways
Thank you, that's allways interesting, but according to those tests Reiser4 is NOT the best filesystem, but the fastest. That is not the same, and I hope you understand that.
Jaap
EXT4 almost as fast
Reiser4 is only slight faster than EXT4 with extents, and default EXT4 isn't too far behind either. On the other hand Reiser4 uses alot less space on disk.
Reiser4 is the fastest and
Reiser4 is the fastest and (by far) the most efficient in disk usage.
I hope you, Jaap, understand that Reiser4 could be and probably is the best filesystem.
ZFS is best filesystem :P
ZFS is best filesystem :P
Yes, where is ZFS in these
Yes, where is ZFS in these benchmarks, was it too embarrassing to include it? :)
that's some "killer"
that's some "killer" performance
Can Reiser4 survive without Hans?
If you read the recent news about Hans Reiser it does not look like he will be available to assist with supporting Reiser4. It is always a great concern when a company or individual is highly associated with a filesystem, i.e. namesys with reiserfs and SGI with XFS, and then those entities become compromised in their ability to help support the filesystem. For example, with XFS all the patches kept coming from SGI even after it was in the kernel tree, and then SGI went bankrupt.
I am sure it would survive
I am sure it would survive if someone picked up the remaining Namesys developers. If not, it probably won't. While Hans was the designer of reiser4, most of the code was written by Namesys employees.
There was a somewhat recent story about the status of reiser4 (link), quoting: "currently there are two namesys employees working [on Reiser4] mostly on enthusiasm." There is a bit of hope in getting it into mainline, but I am not optimistic at this point.
On the reiserfs-devel mailing list (which recently moved to reiserfs-devel AT vger.kernel.org), Edward Shiskin is still active, fixing bugs and churning out irregular releases.
not convinced yet
Ok, you work with highly compressible data (linux sources), so no wonder that it is fast.
But what if you use a slow processor? Please give benchmark results indicating the performance loss due to slow processors.
And how does the benchmark perform when using non-compressible data? Or non-text like binaries, executables, libraries?
The benchmark shown above just cannot show the truth as the simulated circumstances have nothing to do with "the real world" [tm].
Or what is the effect of
Or what is the effect of compresson on library access for dynamically linked executables? I guess it produces a lot of overhead because the system will only access random parts of the library, but -- as we all probably know -- compression usually requires the decompression of whole blocks of data.