Announcement

Collapse
No announcement yet.

NixOS Takes Action After 1.2GB/s ZFS Encryption Speed Drops To 200MB/s With Linux 5.0+

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

  • #21
    Originally posted by skeevy420 View Post
    Is the Nvidia driver a novelty? Nope.
    Debatable. But novelty or not, it's not worth the extra effort required, when the mainline AMD drivers work so well. Why would a Linux user bother with nvidia anymore in 2019?? Same goes for ZFS.

    Comment


    • #22
      Originally posted by torsionbar28 View Post
      Debatable. But novelty or not, it's not worth the extra effort required, when the mainline AMD drivers work so well. Why would a Linux user bother with nvidia anymore in 2019?? Same goes for ZFS.
      While I'm an AMD user, Nvidia supposedly has better OpenCL support, machine learning and AI stuff, they have the highest performing GPUs in regards to games according to Michael's benchmarks, they have better power to performance ratios...plenty of reasons to choose Nvidia.

      I personally wouldn't choose them, but all I care really about is a working desktop and games and AMD delivers that in spades with open source goodness that gives great long term support that, in turn, helps make spiffy projects like gallium-nine and dkvk-ags possible.

      As for ZFS, that's simple, feature for feature it's the best around and no other file system compares to it. BTRFS on LVM on LUKS is the closest Linux/GPL analog to what ZFS contains in a single, coherent package and tool-set. I became a ZFS user because I'd rather learn and deal with just ZFS over BTRFS and LVM and LUKS. My only real issue with ZFS is dealing with boot loaders...but that's a problem that I know that BTRFS and LUKS have had from time to time so it's hard to blame that on just ZFS and really falls back on my earlier comment of "use out-of-tree stuff, deal with out-of-tree problems".

      I'd love some Linux/GPL-only, self-contained file system that does what ZFS does, and if we had it, I'd use it. Call me weird, but random file system over separate volume manager over separate encryption manager just seems like trouble waiting to happen.

      Comment


      • #23
        Originally posted by jpg44 View Post
        It seems like this removal was simply made out of spite against people who were using ZFS and for no other reason.
        I would not say so. The reworked functions are using RCU and other known patent techs in ways they were not before. That is interesting problem is there a issue there or is there not.

        Comment


        • #24
          Originally posted by debianxfce View Post

          Redhat software is intentionally badly designed, implemented, buggy, difficult use and slow. Examples: gnome3,pulseaudio,systemd,networkmanager and polkit. Virtualbox works fine when the vbox driver compiles with your kernel.
          Virtualbox is far inferior to KVM/QEMU. What the fuck are you talking about.

          Comment


          • #25
            Originally posted by jpg44 View Post
            It seems like this removal was simply made out of spite against people who were using ZFS and for no other reason.
            It was all clearly described in the commit that removed it, it was deprecated for a long while and then the last module using this interface stopped using it.

            Comment


            • #26
              Originally posted by debianxfce View Post
              Redhat software is intentionally badly designed, implemented, buggy, difficult use and slow. Examples: gnome3,pulseaudio,systemd,networkmanager and polkit. Virtualbox works fine when the vbox driver compiles with your kernel.
              The only "intentionally badly designed, implemented, buggy, difficult use and slow" in that list is GNOME3, and it would still be a stretch. It's not THAT bad.

              Comment


              • #27
                Let's freeze this hate train a second and point out that the application does not need to ask the kernel to use AES-NI or any other CPU instruction directly, which is what it should have been doing all along.

                (OpenSSH for example does it, so does OpenVPN)

                Comment


                • #28
                  Originally posted by debianxfce View Post
                  KVM/QEMU can be developed without redhat
                  so does Virtualbox

                  Comment


                  • #29
                    Originally posted by blackiwid View Post
                    Would all this bsd lovers really like to have a fully integrated zfs in Linux? Then bsd would loose the only feature anybody uses their OS for. (except big companies for proprietary stuff). Good the zfs code could become better through more devs but therefor the users that use bsd would go down drastically from a very low point already.
                    The only thin foiled hat thing I could think of is that they would see it as reason to split the Linux community and weaken the Linux marketing / progression with that

                    Every one that wants it in Linux sounds to me like a guy that says please I hate BSD so much let me use it in Linux that I don't have to use bsd anymore, but that might be my fantasies.

                    But yes I see no reason to use openzfs this target audience the enterprises wouldn't they use just the oracle stuff that is newer and better? Why use the amateur fork? It's for me like guy that goes to schools and gives a small dosage of drug for free to the children then later they will get the hard stuff from Oracle
                    You know, you "linux-lover" (Yeah, I can be equally sneeringly derogatory), I won't mind personally. ZoL will never be "fully integrated". CDDL/GPL2 conflict does not allow it. It's permissible on BSD though.

                    Due to being out of tree, ZoL is going to be under much tighter constraints than ZoF and will forever face more issues, leaving enough advantages to BSD - while retaining compatibility. ZoF does not have to deal with dkms nor find ways around if kernel devs decide to break/lose something they'd need. Title of this article is just one of examples fitting the pattern.

                    Comment


                    • #30
                      Originally posted by starshipeleven View Post
                      Let's freeze this hate train a second and point out that the application does not need to ask the kernel to use AES-NI or any other CPU instruction directly, which is what it should have been doing all along.

                      (OpenSSH for example does it, so does OpenVPN)
                      Nope, they can't. When you do something with the FPU or SSE registers in the kernel, you need to save their previous state, and then restore them back to their old contents when you're done. The kernel saves/restores the common registers for you, but the math ones are more rarely used, so it saves time overall to not automatically do this on every interrupt and syscall. The functions that were removed and replaced with GPL-only ones are exactly these save/restore ones.

                      The reason OpenSSH and OpenVPN can do whatever they want is that they do it in userland, not in the kernel. Whenever there is a kernel/userland transition (syscalls, interrupts, the scheduler thinks it's time to switch task), the kernel does save/restore these registers. ZFS is a file system, so unlike vpn and ssh it has to work without any userland service running.

                      Comment

                      Working...
                      X