Announcement

Collapse
No announcement yet.

An Update On Reiser4 For The Mainline Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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)

    Comment


    • #3
      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???

      Comment


      • #4
        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?

        Comment


        • #5
          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 ?

          Comment


          • #6
            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

            Comment


            • #7
              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

              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.

              Comment


              • #8
                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
                *) ...

                Comment


                • #9
                  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

                  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

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      Anyone knows why these patches aren't working:
                      http://www.kernel.org/pub/linux/kern...iser4-for-2.6/



                      Edit: for 2.6.37

                      Comment


                      • #12
                        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
                        Btrfs also allows this. I've been seeing patches that allow this in the mailing lists a while back. No idea when it'll trickle down to distribution repositories though.

                        Btrfs also determines which blocks are compressible, although you can force it to compress all blocks using a mount option (not sure what it is)

                        Comment


                        • #13
                          If they say it's ready then I'd say give it a chance on mainline. Though people have gotten in trouble for code dumping before and history shows that going mainline doesn't necessarily attract volunteers to maintain said dumped code blob. If things start breaking and nobody cares they shouldn't have any reservations about removing it either.

                          Comment


                          • #14
                            I haven't heard of this "reiserfs" thing, is it new? I have heard of hans reiser though, he's the developer behind murderFS, right?


                            Joking aside, no major vendor is going to go for murderfs because of its association with... murder. They figure that its the equivalent of catching the plague -- nobody hangs around after you've got it.

                            Comment


                            • #15
                              Originally posted by droidhacker View Post
                              I haven't heard of this "reiserfs" thing, is it new? I have heard of hans reiser though, he's the developer behind murderFS, right?


                              Joking aside, no major vendor is going to go for murderfs because of its association with... murder. They figure that its the equivalent of catching the plague -- nobody hangs around after you've got it.
                              Dumbest comment ever. MurderFS? Are u kidding me? But yes, reiser4 was cool back then, now BTRFS is the next big thing in linux.

                              Comment

                              Working...
                              X