Page 3 of 3 FirstFirst 123
Results 21 to 25 of 25

Thread: Reiser4 Benchmarked On Linux 3.5

  1. #21
    Join Date
    Feb 2012
    Posts
    71

    Default FTRFS

    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 ?

  2. #22
    Join Date
    Sep 2011
    Posts
    171

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    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.

  3. #23

    Default

    Quote Originally Posted by curaga View Post
    ..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.

    Quote Originally Posted by disi View Post
    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/

    Quote Originally Posted by curaga View Post
    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.
    Last edited by ryao; 10-18-2012 at 07:44 AM.

  4. #24
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    255

    Default

    Quote Originally Posted by Rallos Zek View Post
    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...

Posting Permissions

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