Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: An Update On Reiser4 For The Mainline Linux Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    14,554

    Default An Update On Reiser4 For The Mainline Linux Kernel

    Phoronix: An Update On Reiser4 For The Mainline Linux Kernel

    In November of 2009 we reported that the Reiser4 file-system may go into the mainline Linux kernel in late 2010. We're now into 2011 with the merge window having closed earlier this month for the Linux 2.6.38 kernel and there's no sign of this open-source file-system designed to succeed the popular ReiserFS. So what gives? Well, we have another update from its lead developer...

    http://www.phoronix.com/vr.php?view=OTA2Mw

  2. #2
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    folks shouldn't be so short-sighted and only focus on performance

    do some data-integrity tests with reiser4 against ext4 and btrfs

    especially cases like power outage, usage with device-mapper and cryptsetup

    soon you'll see that there is corruption going on with btrfs (still regularly at the moment for me, during hardlocks the superblock get unrecoverable corrupted; data loss, etc.), ext4 (there might be but there were lots of fixes in the last merge window - in the past I regularly got corruptions or data loss during usage of suspend-to-disk and tuxonice), reiser4 (I had some due to upstream doing some serious changes in the kernel, currently no that I know of)

  3. #3
    Join Date
    Jan 2009
    Posts
    1,621

    Default

    why would it need a vendor behind it if it is in fact ready

    even if there is no official vendor behind it the community -and there are people that use it- might help

    has he tried sending the patches to lkml or something???

  4. #4
    Join Date
    Jan 2011
    Posts
    4

    Default Who cares?

    The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?

  5. #5
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by Abn0rmal View Post
    The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?
    because it DOES NOT KILL your data RIGHT NOW ?

    and it's simply superior due to its concept behind it ?

  6. #6
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    Quote Originally Posted by Abn0rmal View Post
    The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?
    Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now

  7. #7
    Join Date
    Feb 2009
    Location
    France
    Posts
    289

    Default

    Quote Originally Posted by kernelOfTruth View Post
    because it DOES NOT KILL your data RIGHT NOW ?

    and it's simply superior due to its concept behind it ?
    I've been using btrfs for about two months and so far, no data loss.

    I can assure you I've tested the power outage problem, it works great for me so far

    Quote Originally Posted by FireBurn View Post
    Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now
    So does Btrfs in the 2.6.38 if I understood "make menuconfig" right.

  8. #8
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by FireBurn View Post
    Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now
    during filesystem creation:
    *) unix40 (regular filesystem mode)
    *) ccreg40 (cryptcompress mode; compression with checksumming; encryption can be added)

    **) compression algorithm: gzip and lzo
    **) compression mode: conv, latt, force, ultim

    *) choosing of cluster-size

    *) fibration-mode: sorting of files by their ending (ext_1_fibre, ext_3_fibre)

    *) extent-mode (for large files)
    *) tails-mode (for lots of small files)
    *) smart-mode heuristically determining whether to use extents or tails

    *) there might be more that I forgot ...

    during mount:

    *) optional additional transaction lookaside buffer (tree.ckb_cache.nr_slots)
    *) flush relocation threshold/distance
    *) number of maximal flushers
    *) number of maximal scanned nodes during flush
    *) set up of optimal io-size
    *) optional 32bit timestamps
    *) BSD-style gid assignment
    *) disabled pseudo files
    *) single flushing (no concurrent flushing)
    *) disabled loading of bitmap during mount (faster mounting of large volumes)

    other characteristics:
    *) dancing (balanced, ...) B-trees
    *) atomic writes
    *) light-weight load on harddrive mechanics
    *) ...

  9. #9
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by MPF View Post
    I've been using btrfs for about two months and so far, no data loss.

    I can assure you I've tested the power outage problem, it works great for me so far
    haha, nice

    I had still serious problems and data corruption with 2.6.37

    Quote Originally Posted by MPF View Post

    So does Btrfs in the 2.6.38 if I understood "make menuconfig" right.
    they moved it ? - so that isn't set anymore during mount

  10. #10
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by kernelOfTruth View Post
    during filesystem creation:
    *) unix40 (regular filesystem mode)
    *) ccreg40 (cryptcompress mode; compression with checksumming; encryption can be added)

    **) compression algorithm: gzip and lzo
    **) compression mode: conv, latt, force, ultim

    *) choosing of cluster-size

    *) fibration-mode: sorting of files by their ending (ext_1_fibre, ext_3_fibre)

    *) extent-mode (for large files)
    *) tails-mode (for lots of small files)
    *) smart-mode heuristically determining whether to use extents or tails

    *) there might be more that I forgot ...

    during mount:

    *) optional additional transaction lookaside buffer (tree.ckb_cache.nr_slots)
    *) flush relocation threshold/distance
    *) number of maximal flushers
    *) number of maximal scanned nodes during flush
    *) set up of optimal io-size
    *) optional 32bit timestamps
    *) BSD-style gid assignment
    *) disabled pseudo files
    *) single flushing (no concurrent flushing)
    *) disabled loading of bitmap during mount (faster mounting of large volumes)

    other characteristics:
    *) dancing (balanced, ...) B-trees
    *) atomic writes
    *) light-weight load on harddrive mechanics
    *) ...
    to make their clear: you have concurrent flushing by default but you can disable it for usb- and other slow devices

Tags for this Thread

Posting Permissions

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