Reiser4 Benchmarked On Linux 3.5

[piotr5]

strange benchmark logs. where is the command used for creating reiser4?
if during creation the flavour cryptcompress was chosen, maybe even with always-compress, it's an unfair comparison. this would explain why it performs so poorly in multithreading: all processors (especially on intel the "cores") are occupied with number-crunching for the compression.
or did the other filesystems have some compression feature turned on too? on ssd compression might be a bad idea anyway...

[mayankleoboy1]

Are there any updates to the "Fractal Tree FS" , based on TokuDB ?
One of TokuDB's employees gave a working presentation of FTRFS on some bigdata summit in July 2012. Any updates since then ?

[Rallos Zek]

Is Reiser4 the "Brain fuck scheduler" of file systems ?
It has merits, and can be developed further to beat a lot of mainline FS's. But it wont be _ever_ introduced in the mainline kernel. For reasons that some critics say are biased against the _developer_ , rather than the technical merit of the code itself.

Reiser4 not being in the Kernel is all about the code quality, which is crap and the developer, he was an ass even to Linus. Please do not compare the awesomeness of BFS to the shittyness of ReiserFS.

[ryao]

..and the fact that it uses a fuckhuge amount of ram to work properly. 1gb minimum was it? Dedicated, only for ZFS at that.

ZFS will give RAM back to the system if your system is under memory pressure. The limit on ARC is the maximum that it will permit itself to use. It by no means prevents your programs from using that memory should they need it.

Here is his guide:
https://github.com/ryao/zfs-overlay/...er/zfs-install
With the option zfs_arc_max for the zfs module, you can restrict the amount of memory used for the cache.

The big problem is with ZFS as rootfs on Linux, you cannot set this parameter as kernel commandline because the module cannot be included into the kernel (licence issues).

It should not be less than 512MB and a good value is 1/4 of available memory.
http://wiki.gentoo.org/wiki/ZFS#Tweak

I need to find time to rewrite that wiki page. That tip is completely wrong. Being less than 512MB is fine. On 32-bit ARM systems, people have set zfs_arc_max to 40MB at my suggestion. A good value is generally leaving it alone because the default of 1/2 works well. That is unless you are on a 32-bit system, where some tuning is necessary for now.

Also, ZFS can be included in the kernel. You just cannot redistribute a kernel binary that contains ZFS support. Here is a link to a slightly dated guide that says how to do this:

https://mthode.org/gentoo-hardened-z...-dm-cryptluks/

Indeed. I'm *not* going to waste min(1/4, 512mb) of my RAM for some FS cache that can't be dropped.

It actually can. Just do echo 3 > /proc/sys/vm/drop_caches.

Anyway, feel free to continue using an inferior page replacement algorithm and endure the lags that occur because your cache is wiped whenever a sudden temporary change in your workload doesn't use anything already in the cache. I will not stop you.

[djdoo]

Reiser4 not being in the Kernel is all about the code quality, which is crap and the developer, he was an ass even to Linus. Please do not compare the awesomeness of BFS to the shittyness of ReiserFS.

How do you get to the conclusion that code quality is crap and what do you mean exactly by that term??
Furthermore performance comparison does not show any shittyness of Reiser4 or even more any awesomeness of Btrfs to my eyes...
Except only if you mean some advanced features btrfs demonstrates like cloning and stuff which for the average user I think are close to meaningless...