Announcement

Collapse
No announcement yet.

Reiser4 & ZFS Get Updated For The Linux 4.4 Kernel

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

  • Reiser4 & ZFS Get Updated For The Linux 4.4 Kernel

    Phoronix: Reiser4 & ZFS Get Updated For The Linux 4.4 Kernel

    For those relying upon the out-of-tree ZFS or Reiser4 file-systems, they have each been updated now to work with this week's release of the Linux 4.4 kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Comparison? Sure ... since reiserfs is still the only filesystem capable of handling certain io loads. Just ask the fastmail.fm guys.

    Comment


    • #3
      Yes, the people want to know! bring it on!

      Comment


      • #4
        Originally posted by pegasus View Post
        Comparison? Sure ... since reiserfs is still the only filesystem capable of handling certain io loads. Just ask the fastmail.fm guys.

        reiserfs is not even related to reiser4 with the exception of name and murderous founder. Totally different filesystems.

        Comment


        • #5
          I am very interested in ZFS compared to Btrf on a modern/recent kernel. I am running ZFS on my system and need to repartition the disks. But the question remains; Continue with ZFS or try out Btrfs instead?
          It would also be VERY interesting to compare ZFS on Linux, BSD and Solaris 11.3. Are the open source version up to speed with the commercial version?

          Comment


          • #6
            Who's interested in a fresh Linux 4.4 file-system comparison of the mainline contenders (F2FS, Btrfs, XFS, EXT4), compared to ZFS and Reiser4? Let me know in the forums if you are interested.
            Interested... but very interested if you include more than the (often significantly differing) default configurations: testing each FS at 1) FS/OS default config, 2) equivalent "performance" configurations, 3) equivalent "conservative" configurations, 4) as 3, with a (common to all FSs) FS encryption option enabled, 5) with a (common to all FSs) FS compression option enabled

            ..and keep a close eye on CPU and memory use throughout - not just raw "performance"

            Much more interesting still if you can manage to run that lot on a couple of disparate platforms... one of your multichip Xeon systems and a Pi zero for example.

            Fingers crossed!

            Edited to second the request for a ZFS on Linux/BSD/Solaris comparison
            Last edited by Dick Palmer; 14 January 2016, 04:21 PM.

            Comment


            • #7
              I'm interested in reiser4 benchmarks. Also, include a comparison with JFS too.

              Comment


              • #8
                I'd be interested in a "Interesting Disk Configuration" review. Things like:
                * How easy is it to setup a 4 disk RAID0, RAID1, RAID 5/6 RAID10 etc
                * Managing a multi disk setup (Adding, removing, expanding)
                * How each filesystem at each level deals with the failure of a disk
                * and of course - the performance of each filesystem/raid level

                Comment


                • #9
                  I am tired of reading commentary by Michael that ZFSOnLinux is not mainline because of licensing differences. Even if ZFSOnLinux were GPL or Linux were CDDL, it is unlikely to go into the mainline kernel. Being mainline would require the ZoL developers to accept the possibility of people running ancient versions of the code thinking that their distributions are porting fixes when in reality, the back porting probably would not happen very much if other filesystem drivers are any indication. Trying to watch all of the kernel branches in use by every distribution in addition to the kernel.org one would tie far too many resources from development to be worthwhile unless someone were willing to do it as a full time job. Other filesystem developers deal with this by not caring. We deal with it by leveraging autotools and being out of tree.

                  A younger version of me was willing to try to make people who thought being mainline is awesome happy by talking to Linus about this. The the first of two times we discussed it, licensing was not a problem. The second time, Linus did not want CDDL code (although he seems to have no problem with BSD). Being older and wiser, there is not going to be a third time. In hindsight, being mainline would not only require us to stop caring about quality across kernel versions, but it would have also cause a conflict between the Linux coding style and that Sun coding style that being out of tree avoids entirely. Being subject to Linux's code style requirements would have made porting patches between platforms a nightmare.

                  The only benefit to anyone from being mainline is not having to worry a out API changes as the people changing the API must change the affected to code to work. However, our autotools' based build system can easily handle the API changes such that a new kernel can be supported with only an hour of effort. Any changes made for us by the mainline developer changing an API would not be made in a backward compatible way and require additional work.

                  Being mainline just is not desirable to any kernel filesystem driver project that cares about supporting many kernel versions equally well and porting patches to/from other kernels.
                  Last edited by ryao; 15 January 2016, 12:27 PM.

                  Comment


                  • #10
                    Originally posted by joecool View Post


                    reiserfs is not even related to reiser4 with the exception of name and murderous founder. Totally different filesystems.
                    While true, both are the workings of the genius madman of Hans Reiser. So you could say Reiser4 was an attempt to do things better.

                    With that said, why is there so many "killer" code writers or Linux advocates? Sad. Life for them has no worth. Time to pray for Linux kernel devs, application devs and Linux leaders and aficionados.




                    Comment

                    Working...
                    X