Announcement

Collapse
No announcement yet.

ZFS File-System For Linux Is Still Around

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

  • ZFS File-System For Linux Is Still Around

    Phoronix: ZFS File-System For Linux Is Still Around

    While Btrfs, XFS, and EXT4 remain the far more popular choices when it comes to Linux file-systems, there still exists projects focused upon providing ZFS file-system support under Linux...

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

  • #2
    However, with FreeBSD, OpenIndiana, and Solaris 11 around - do you really want to?

    Comment


    • #3
      ZFS On Linux Recognition

      I've asked myself why there's been little recognition from Phoronix to recognize the ZoL ( ZFS on Linux ) project over the last year or so. It's good to see a writeup again, and hopefully we'll see some benchmarks soon. I'd like to see ZoL compared to ZFS Fuse and ZFS under a BSD.

      A lot of work has been done on this project and the forums are very helpful. ZoL performs extremely well for myself and many others. Illumos ZFS bugs are frequently merged into the ZoL code base too.

      The latest version even provides the .zfs/snapshot folder where you can see all your snapshots without having to do any additional mounts--great stuff!

      It's very simple and quick to install from source code too. Checkout, compile, and install can be done within 10 minutes time for anyone who has ever run a ./configure script and compiled source code.

      It's unfortunate with the licensing issue that it can't be stock included with the kernel, but all the source code is available, and easy to get up an running on any system. I've lived with binary NVIDIA blobs for years now, so I don't have an issue having to do an occasional git pull and recompile/install to pull in the latest code from ZoL .

      While there are many features and knobs to tune and control ZFS, the only tunable I need to make it work great for me is to limit the amount of memory used for the ARC . A modprobe.d file option:

      options zfs zfs_arc_max=1610612736

      works for me to limit the amount of memory of the cache.

      I've been running ZoL for a while now on a 5 disk 4TB ( 2 mirrored pairs, 1 hot spare, and 4 old 1GB usb flash cache devices ) array using several compressed and uncompressed filesystems. I perform all my nightly backups there from several computers, run a postgres tablespace with compression on it, and run a few KVM images off of it, and serve up video files for streaming to several devices. I've not run into any issues.

      Comment


      • #4
        ZfsonLinux requires your kernel to be non SMP.

        Comment


        • #5
          SMP works just fine. The restriction is on the preemption model: You can't use CONFIG_PREEMPT ( low latency desktop ) , you need either CONFIG_PREEMPT_VOLUNTARY or CONFIG_PREEMPT_NONE .

          Linux xxxxxx 3.3.4+ #8 SMP Fri Apr 27 15:30:00 MDT 2012 x86_64 x86_64 x86_64 GNU/Linux

          Comment


          • #6
            If ZFS wants to survive outside Solaris and their Open Source forks, a dual licensing must be made in some form and included into the vanilla kernel.

            Other than that, this is like the fanatics wanting to use Reiser4 into Linux 3.x. It's just a pipe dream that's going nowhere.

            Please be more realistic, even HAMMER2 is a more viable option once Matt Dillon agrees on some kind of interoperatibility between non-BSD UNIX-like systems.

            But what about Btrfs?

            What about distributed file systems? CRFS, FhGFS, Tahoe-LAFS, Ceph, Lustre, MooseFS, GFS2, OCFS, OneFS, XtreemFS, GlusterFS, HAMMER2 (seems it will have those features), pNFS, AFS.

            What I mean is not just a new, scalable and proper and efficient network filesystem, but also RAID-like capabilities. That could make commodity hardware to get into cheap RAID solutions to avoid data losing.



            So what about an article about that instead beating a dead horse like ZFS? Despite all the hype in the past, it reduces interoperability between al UNIXes (and non-UNIXes).

            Comment


            • #7
              Originally posted by timofonic View Post
              If ZFS wants to survive outside Solaris and their Open Source forks, a dual licensing must be made in some form and included into the vanilla kernel.

              Other than that, this is like the fanatics wanting to use Reiser4 into Linux 3.x. It's just a pipe dream that's going nowhere.

              Please be more realistic, even HAMMER2 is a more viable option once Matt Dillon agrees on some kind of interoperatibility between non-BSD UNIX-like systems.

              But what about Btrfs?

              What about distributed file systems? CRFS, FhGFS, Tahoe-LAFS, Ceph, Lustre, MooseFS, GFS2, OCFS, OneFS, XtreemFS, GlusterFS, HAMMER2 (seems it will have those features), pNFS, AFS.

              What I mean is not just a new, scalable and proper and efficient network filesystem, but also RAID-like capabilities. That could make commodity hardware to get into cheap RAID solutions to avoid data losing.



              So what about an article about that instead beating a dead horse like ZFS? Despite all the hype in the past, it reduces interoperability between al UNIXes (and non-UNIXes).
              The other thing I've heard about ZFS is it's a RAM hog. You need at least 2GB just to get going with it.And if I play games or just want a good desktop experience isn't low-latency essential?

              Hammer2 looks interesting.

              I would also like to hear about any updates from NilFS.

              Comment


              • #8
                Originally posted by timofonic View Post
                If ZFS wants to survive outside Solaris and their Open Source forks, a dual licensing must be made in some form and included into the vanilla kernel.
                BSDs are not Solaris forks.

                Dual licensing? ZFS source is now closed.

                I have to wonder, why does Oracle develop Btrfs, the main competitor to ZFS, while now keeping the source for ZFS version > 28 closed? Someone in management must not realise that they are killing their flagship product with another -> when they do, Btrfs will probably die.

                Other than that, this is like the fanatics wanting to use Reiser4 into Linux 3.x. It's just a pipe dream that's going nowhere.

                Please be more realistic, even HAMMER2 is a more viable option once Matt Dillon agrees on some kind of interoperatibility between non-BSD UNIX-like systems.

                But what about Btrfs?
                What about it? It's years behind ZFS in features (eg. no RAID 5 yet) and receives a lot less testing.

                What about distributed file systems? CRFS, FhGFS, Tahoe-LAFS, Ceph, Lustre, MooseFS, GFS2, OCFS, OneFS, XtreemFS, GlusterFS, HAMMER2 (seems it will have those features), pNFS, AFS.
                Many of those don't follow POSIX consistency semantics and are thus unsuitable for eg. running databases.

                What I mean is not just a new, scalable and proper and efficient network filesystem, but also RAID-like capabilities. That could make commodity hardware to get into cheap RAID solutions to avoid data losing.



                So what about an article about that instead beating a dead horse like ZFS? Despite all the hype in the past, it reduces interoperability between al UNIXes (and non-UNIXes).
                ZFS has RAID-Z, a feature not yet found in any competitor.

                The infectious restrictions of the GPL reduce interoperability in this case, not ZFS itself.

                Comment


                • #9
                  Originally posted by linuxoid View Post
                  The other thing I've heard about ZFS is it's a RAM hog. You need at least 2GB just to get going with it.And if I play games or just want a good desktop experience isn't low-latency essential?.
                  It only hogs RAM (2GB per TB of disk storage) if you use deduplication, doesn't it?

                  Comment


                  • #10
                    Originally posted by dacha View Post
                    Dual licensing? ZFS source is now closed.
                    Don't you think this reduces interoperability?

                    The infectious restrictions of the GPL reduce interoperability in this case, not ZFS itself.
                    What stops them from releasing ZFS under the BSD license? GPL is there for good reasons and it's the best license when you want to compete with other projects. However, its restrictions have nothing to this thread and strange Oracle's behavior.
                    Last edited by kraftman; 05-07-2012, 05:43 AM.

                    Comment


                    • #11
                      Originally posted by kraftman View Post
                      Don't you think this reduces interoperability?
                      Yes. But even if Btrfs doesn't die, Btrfs and its GPL licence puts other *nix systems in exactly the same position as ZFS is on Linux: they can use it, but they can't distribute it with their kernel. This isn't any better for interoperability.



                      What stops them from releasing ZFS under the BSD license? GPL is there for good reasons and it's the best license when you want to compete with other projects. However, its restrictions have nothing to this thread and strange Oracle's behavior.
                      One of the disadvantages of the BSD license to users, is that it doesn't grant you a patent licence on the code, like eg. ZFS's CDDL does.

                      Comment


                      • #12
                        Originally posted by dacha View Post
                        Yes. But even if Btrfs doesn't die, Btrfs and its GPL licence puts other *nix systems in exactly the same position as ZFS is on Linux: they can use it, but they can't distribute it with their kernel. This isn't any better for interoperability.
                        This is true what you said, but while ZFS is now closed source the possibility of killing btrfs is much lower now.

                        Comment


                        • #13
                          If you want to use ZFS just use BSD.

                          The only reason why the Lawrence Liverpool people want to use ZFS on Linux is because they hit the limits of the Ext4-based storage for their Lustre backends.

                          Comment


                          • #14
                            Also nowadays, because of going back to closed source, ZFS has two major forks:
                            1. Solaris ZFS
                            2. Open Source ZFS

                            Solaris ZFS can read and import Open Source ZFS, but the reverse is not true. ZFS is backwards compatible, but not forward compatible and the Solaris ZFS has new features that the Open Source ZFS does not have.

                            Yes. But even if Btrfs doesn't die, Btrfs and its GPL licence puts other *nix systems in exactly the same position as ZFS is on Linux: they can use it, but they can't distribute it with their kernel. This isn't any better for interoperability.
                            Well.
                            A) Oracle can't close source BTRFS like they did with ZFS. The reason being is that while they did sponsor the development originally and hosted the websites for it originally they do not own the copyrights.

                            B) It's a Linux file system shares code extensively with Linux-VFS, So it's a derivative and has to be licensed GPL.

                            C) Portable file systems were never much of a priority for anybody. Unix systems, including BSD, used UFS/FFS fairly universally. Even OS X supported it. However they tended to introduce subtle changes and assumptions so that even though they share a common code base portability was undermined.

                            Comment


                            • #15
                              Originally posted by drag View Post
                              Also nowadays, because of going back to closed source, ZFS has two major forks:
                              1. Solaris ZFS
                              2. Open Source ZFS

                              Solaris ZFS can read and import Open Source ZFS, but the reverse is not true. ZFS is backwards compatible, but not forward compatible and the Solaris ZFS has new features that the Open Source ZFS does not have.
                              Also the opposite. Please see Fork Yeah! The Rise and Development of illumos and ZFS Feature Flags. Especially the first video mentions (around 44 min) that previous ZFS key developers quit at Oracle and are now contributing to the open source version.

                              Comment

                              Working...
                              X