Announcement

Collapse
No announcement yet.

ZFS On Linux Landing Workaround For Linux 5.0 Kernel Support

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

  • #41
    Originally posted by oiaohm View Post
    https://github.com/zfsonlinux/zfs/wi...e-requirements Having a starting requirement of 8G of memory is not good.
    I find it funny how people always miss the full quote there.

    • 8GB+ of memory for the best performance. It's perfectly possible to run with 2GB or less (and people do), but you'll need more if using deduplication.
    So, you can run ZFS on a system with 2GB or less of RAM, but if you want the best performance, get more, especially if you want to do deduplication. That's a far cry from a "starting requirement" there.

    Comment


    • #42
      Originally posted by Almindor View Post
      They're not doing any such thing. This api was flagged deprecated for a bloody decade.
      users which just want to use something are not interested in facts

      Originally posted by Almindor View Post
      The arrogance is Oracle/whoever is behind ZFS here. They should've fixed around this by now or relicensed. Upstream has no reason to provide anything here, they marked it deprecated long enough for the ZFS guys to react. Now that it's being removed people blame Linux devs for it. Ridiculous.
      ZOL has nothing in common with Oracle long ago, but yes that all is ridiculous, look at trools like "Weasel" which argues completly of assumptions and "i want", "i believe", "i do not know but they for sure have a reason" and so on

      Comment


      • #43
        Originally posted by Niarbeht View Post
        So, you can run ZFS on a system with 2GB or less of RAM, but if you want the best performance, get more, especially if you want to do deduplication. That's a far cry from a "starting requirement" there.
        https://access.redhat.com/documentat...ig-index-reqts

        Problem is 2G or less you can do deduplication with btrfs or xfs/vdo solutions.

        2GB is xfs with vdo(that is with deduplication) for up to 50TB of storage. This is a best performance number. Very much more detailed best performance numbers. ZFS numbers are not great.

        Comment


        • #44
          Originally posted by Weasel View Post
          Gee, maybe because they could have used the normal (non-SIMD) path without having the functions removed, and yet didn't do it for obvious reasons?

          I didn't do benchmarks, but I'm pretty sure the ZFS guys who wrote the SIMD checksumming (or ported it, w/e) did when implementing it. It's there for a reason.
          Problem is the Linux kernel scheduler has changed since the ZFS guys did that.

          https://linuxplumbersconf.org/event/...ributions/194/
          What to do after PREEMPT_RT is accepted into mainline
          This means your messing around with the FPU now need to take out a protective lock. The performance profile since the merge of PREEMPT_RT is very different. Yes OpenSolaris/Illumos kernel does not have PREEMPT_RT and this is where ZoL accelerated SIMD check-summing comes from.

          Sorry what was obvious reason to-do something under a Solaris/illumos kernel could be totally stupidity on the newer Linux kernel. Yes using SIMD by the FPU instruction is triggering locking that need to be PREEMPT_RT compatible.

          Gee they have ported something from a different OS to Linux that may not in fact be compatible any more and it not only because the functions were removed the scheduler inside the Linux kernel now is now nothing like a OpenSolaris/Illumos kernel scheduler.

          Basically we need the benchmarks. Linux 5.0 and newer kernels have the PREEMPT_RT stuff as default feature.

          Comment


          • #45
            Originally posted by hreindl View Post
            prove the performance impact by benckmarks
            YOU bring the numbers that it's not affected by this change. Changes require justification not the other way around, dummy.

            Comment


            • #46
              Originally posted by starshipeleven View Post
              If this is true then please explain why NO OTHER module inside the linux kernel was using that. The only user for a long while was some UEFI-related infrastructure thing.

              Are you saying Torvalds used his thought-police to "convince" them not to? Is everyone but ZOL developers (and you) a moron?
              I find it hard to believe Clear Linux for example doesn't use something similar. But of course it's a "patched" kernel and not "mainline", just like distro kernels are. If mainline was so good then nobody would patch it up.

              Comment


              • #47
                Originally posted by hreindl View Post
                ZOL has nothing in common with Oracle long ago, but yes that all is ridiculous, look at trools like "Weasel" which argues completly of assumptions and "i want", "i believe", "i do not know but they for sure have a reason" and so on
                At least I can spell "troll" properly and my assumptions are based on logic.

                Your bullshit diarrhea on the other hand, which is provably wrong (refer to prior pages about the "implement the checksum themselves" you said) truly qualifies for trolling.

                Comment


                • #48
                  Originally posted by Weasel View Post
                  YOU bring the numbers that it's not affected by this change. Changes require justification not the other way around, dummy.
                  nope, you pretend they do - prove it or shut up
                  you are a poor enduser claming things backed by shit freshly pulled from his arse

                  Comment


                  • #49
                    Originally posted by oiaohm View Post
                    Problem is the Linux kernel scheduler has changed since the ZFS guys did that.

                    https://linuxplumbersconf.org/event/...ributions/194/
                    What to do after PREEMPT_RT is accepted into mainline
                    This means your messing around with the FPU now need to take out a protective lock. The performance profile since the merge of PREEMPT_RT is very different. Yes OpenSolaris/Illumos kernel does not have PREEMPT_RT and this is where ZoL accelerated SIMD check-summing comes from.

                    Sorry what was obvious reason to-do something under a Solaris/illumos kernel could be totally stupidity on the newer Linux kernel. Yes using SIMD by the FPU instruction is triggering locking that need to be PREEMPT_RT compatible.

                    Gee they have ported something from a different OS to Linux that may not in fact be compatible any more and it not only because the functions were removed the scheduler inside the Linux kernel now is now nothing like a OpenSolaris/Illumos kernel scheduler.

                    Basically we need the benchmarks. Linux 5.0 and newer kernels have the PREEMPT_RT stuff as default feature.
                    this guy is proven not interested in technical facts

                    Comment


                    • #50
                      Originally posted by Weasel View Post
                      I find it hard to believe Clear Linux for example doesn't use something similar. But of course it's a "patched" kernel and not "mainline", just like distro kernels are. If mainline was so good then nobody would patch it up.
                      come on and show me the massive pacthes of Fedora

                      the don't exist because they are way to expensive to maintain given the rebase every few weeks and other than you i run it in production from telephony over database and whatever network usecase you can imagine for long enough

                      BRUHAHAHAHA "something similar" - just inform youself what clean linux is and how it gains the performacne, mostly by compiler flags and automatic vecorization

                      Comment

                      Working...
                      X