Announcement

Collapse
No announcement yet.

FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux

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

  • FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux

    Phoronix: FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux

    With ZFS On Linux (ZOL) being more actively developed than the ZFS file-system code within the OpenSolaris-derived Illumos kernel, FreeBSD will be transitioning their ZFS file-system kernel driver to be based on ZOL...

    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
    I wonder how much disruption is this change going to cause - due to differences between ZFS implementations and yet another porting.. ZFS on FBSD from Illumos has been pretty stable. It's bound to cause at least some.

    Until now, if we wanted to use ZFS, we needed Solaris compatibility ABI shim to be loaded (kernel module). Will Linux's iteration of ZFS make us running Linux ABI mandatory too? I'd rather not because it increases attack surface..

    Comment


    • #3
      I would rather see solaris compatibility layer go away and some effort spent of making ZFS work with whatever underlying kernel offers. Would make many things much more simple ...

      Comment


      • #4
        Originally posted by aht0 View Post
        I wonder how much disruption is this change going to cause - due to differences between ZFS implementations and yet another porting.. ZFS on FBSD from Illumos has been pretty stable. It's bound to cause at least some.

        Until now, if we wanted to use ZFS, we needed Solaris compatibility ABI shim to be loaded (kernel module). Will Linux's iteration of ZFS make us running Linux ABI mandatory too? I'd rather not because it increases attack surface..
        I don't think it'll cause much disruption at all. If anything, it will make things easier since we'll have one version of ZFS that works with Solaris and one version of ZFS that works everywhere else. That's actually a good thing, IMHO. The year of transition and upgrades for BSD users once this goes live will likely be the only time there will be issues; but for fresh installs or new BSD users, it won't really matter outside of oddball scenarios or people using ZFS with both Solaris and not-Solaris.

        AFAIK, the compatibility shim is still there, the two modules were just combined; I assume due to kernel module dependency tracking issues that made kernel updates "pleasant" and "fun" experiences.

        Comment


        • #5
          I knew things were bad on the FreeBSD side, but I didn't think it was so bad that they were unable to backport the ZOL fixes to ZFS. ZFS is the crown jewel of FreeBSD, and now they don't even have that.

          This should be a case study of terrible management. A fish rots at the head first.

          Comment


          • #6
            Originally posted by aht0 View Post
            I wonder how much disruption is this change going to cause - due to differences between ZFS implementations and yet another porting.. ZFS on FBSD from Illumos has been pretty stable. It's bound to cause at least some.

            Until now, if we wanted to use ZFS, we needed Solaris compatibility ABI shim to be loaded (kernel module). Will Linux's iteration of ZFS make us running Linux ABI mandatory too? I'd rather not because it increases attack surface..
            This don't make much sense:

            1.) SPL still exists but it is integrated on ZFS module now instead of separated
            2.) SPL as far as i know still exists on BSD as quoted on the mailing list
            "The sources for FreeBSD's ZFS support are currently taken directly
            from Illumos with local ifdefs to support the peculiarities of FreeBSD
            where the Solaris Portability Layer (SPL) shims fall short"

            hence it doesn't add any attack surface that weren't there before
            3.) Since SPL exist on both they can easily migrate their SPL back code into ZOL and ZFS should run mostly unmodified(i do expect some features specially on the crypto may need some abstraction)

            Remember they are doing this simply because is easier to work with ZOL team than rely on Open/Solaris team that Oracle pretty make sure was non-existant at this point.

            I would not discard that in the future open iteration of solaris will actually switch to work with the ZoL/FreeBSD team as well instead of spent their time begging Oracle for scraps

            Comment


            • #7
              Originally posted by AndyChow View Post
              I knew things were bad on the FreeBSD side, but I didn't think it was so bad that they were unable to backport the ZOL fixes to ZFS. ZFS is the crown jewel of FreeBSD, and now they don't even have that.

              This should be a case study of terrible management. A fish rots at the head first.
              Is not a BSD problem since it also affect Darwin version, the problem is basically on the open/Solaris side of things since Oracle is keeping ZFS behind walls and the current team prolly don't have the manpower to handle the codebase, hence it put BSDs on a very bad spot.

              1.) do we fork? do Darwin guys Fork? wait weeks or month to get response to our patches?
              2.) join forces with another team?

              Hence instead of forking their own FreeBSD ZFS project they took option 2 and are joining forces with ZoL community that have way more manpower and a proven open development model.

              Comment


              • #8
                Originally posted by jrch2k8 View Post

                Is not a BSD problem since it also affect Darwin version, the problem is basically on the open/Solaris side of things since Oracle is keeping ZFS behind walls and the current team prolly don't have the manpower to handle the codebase, hence it put BSDs on a very bad spot.

                1.) do we fork? do Darwin guys Fork? wait weeks or month to get response to our patches?
                2.) join forces with another team?

                Hence instead of forking their own FreeBSD ZFS project they took option 2 and are joining forces with ZoL community that have way more manpower and a proven open development model.
                Is this accurate? My impression was that FreeBSD ZFS was forked a long time ago from openSolaris, which is that whole illumos deal.

                Comment


                • #9
                  Originally posted by aht0 View Post
                  Until now, if we wanted to use ZFS, we needed Solaris compatibility ABI shim to be loaded (kernel module). Will Linux's iteration of ZFS make us running Linux ABI mandatory too? I'd rather not because it increases attack surface..
                  From what I understand by reading the mailing list post, this is happening because the main sponsor of ZFS development on Illumos has decided they migrate to Linux/ZOL, so the Solaris/Illumos ZFS codebase is basically going in life support. I doubt they want to have any ties with Illumos/Solaris codebase in any way now.

                  They clearly say the plan to add FreeBSD support to ZOL project (by January), and afaik ZOL does not require any Solaris shim on Linux. Given these two data points I'd say you will either swap shim or do without, not use both shims at the same time.

                  I'm all for it, consolidate all parties on a single project.

                  Comment


                  • #10
                    Originally posted by AndyChow View Post
                    I knew things were bad on the FreeBSD side, but I didn't think it was so bad that they were unable to backport the ZOL fixes to ZFS.
                    According to what they say ZOL does have significant more features than their current Illumos upstream.
                    It's not about fixes, but about development speed.

                    Comment

                    Working...
                    X