Announcement

Collapse
No announcement yet.

Linus Torvalds Doesn't Recommend Using ZFS On Linux

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

  • I posted this on Slashdot, but I'll reiterate it here. I have nothing to say about licensing; the situation is what it is. This is a purely technical argument for why ZFS is still unique, and fills a common need in a way that no in-tree FS does.

    There are a lot of comments asking "why ZFS" but most of them don't really understand the main killer feature of ZFS (and ZFS on Linux): the ability to efficiently use tiered storage.

    See, there's currently a problem overall with the storage industry. Flash storage, aka SSDs, is hideously expensive per gigabyte. Magnetic storage, aka HDDs, is hideously slow in terms of IOPS. For difficult workloads that require an optimization of server purchase price, high IOPS, and large quantities of local storage, Tiered Storage is the only real option.

    This allows you to buy both: (1) relatively inexpensive, high write endurance but fairly low capacity SSDs -- usually on the order of 128 to 512 GB, depending on the size of the HDDs behind them; and (2) relatively inexpensive, high capacity but slow HDDs -- usually 8 TB or larger -- and combine them into one logical block device that *behaves* as if it were an SSD with many terabytes of storage. You get about 98% of the IOPS performance of the SSDs, while all the data ultimately persists to the HDDs behind the scenes. This is remarkably good for large databases and file storage servers, and the price of building all of that capacity in datacenter-grade SSDs is going to run you about $1000 more per terabyte of capacity, assuming RAID-1 redundancy.

    With ZFS, you can set up your ZFS Intent Log (ZIL) -- basically a write buffer for the HDDs -- on a partition about 25-50% of the SSD capacity (depending on how write-intensive your workload is), and set up the ZIL in RAID-1 mode for data safety. ZFS will then efficiently create large batch sequential writes to the HDD that convert what could be thousands of SSD IOPS (small writes from a database, for instance) into a few dozen HDD IOPS. This allows your storage array to absorb even tens of gigabytes of random writes at hundreds of megabytes per second into the SSDs, which then get reorganized, optimized, and streamed to the HDDs sequentially in a way that optimizes throughput for the HDDs. And program-level calls to sync() or fsync() can legitimately return after completing the writes to the ZIL, even if the writes are still pending to the HDDs, because the data is genuinely on persistent storage that will survive a power outage.

    You can also have an L2ARC (Level 2 Adaptive Replacement Cache) with ZFS, which is basically a page cache for *reading* from the HDDs that sits on a partition in the SSDs. For my servers, I set up the L2ARC to consume about 75% of the space of the SSDs because I don't tend to get very large bursty writes on my workload, but for those with a much higher write workload they will want to increase the percentage of ZIL vs. L2ARC.

    Once again, like the ZIL, the advantage of L2ARC is to reduce the workload on the HDDs and reduce the IOPS demanded of them. The ARC algorithm has also been mathematically proven to be generally more efficient at common page cache workloads than the page cache algorithm the Linux kernel uses for other filesystems, so there's a "Layer 1 ARC" in RAM, too. And it's adjustable in size so you can tune whether you want to suck up lots of RAM with ARC, or leave more RAM for application data.

    For those who would just have HDDs and use RAM buffers to insulate the storage from high IOPS, RAM has three major limitations: one, it's volatile, so it can't safely cache writes for very long; two, using RAM for filesystem caching competes with applications that want to allocate RAM for their own purposes; and three, RAM is very expensive. Also, it's much easier to expand the amount of storage in a server than to expand the amount of RAM: if you have the max. amount of RAM your motherboard supports, you'd have to buy an entire new system to get more. With storage, you can usually just attach another drive, pair of drives, or worst case attach another SATA, SAS, or NVMe card onto the PCIe bus using a spare slot for even more storage. Long story short, you can have a much smaller scale system with terabytes upon terabytes of HDD or even SSD storage, but servers with a couple terabytes of RAM are absolutely enormous, come at a massive cost premium, and require special planning for power, rack space, and system administration, which usually isn't required if you just add a few storage devices.

    So, if you want the best of all worlds, being able to use relatively inexpensive commodity hardware (like single-slot Xeon, or even desktop-grade hardware like Threadripper) but have excellent performance for workloads like databases, game servers and so on -- anything that demands a lot of small writes -- your most affordable path is to use Tiered Storage.

    You would think that Linux would have a stable, mature, tested, highly optimized filesystem in-house for handling Tiered Storage properly, but it actually doesn't. Not at all. None of the solutions available with Btrfs, XFS, Ext4, LVM2, MD, and family even come close to the performance and feature-set of ZFS with tiered storage. Not to mention that the closest feature competitor, Btrfs, is still such a boondoggle stability-wise that Red Hat is abandoning it as a supported filesystem in RHEL. They also don't have any engineers to work on it, but if it were stable, they wouldn't need to.

    I will continue to use ZFS on Linux (at my own peril? Fine.) until Linux offers an in-kernel alternative that matches its performance, featureset and maturity. LLNL has the right idea -- they knew what they were doing when they invested so many dollars into the development of ZoL. They needed a tool that didn't exist, so they built one.

    And no, running a Solaris or BSD kernel probably isn't a viable alternative, when most all software is designed and tested for Linux, and the BSD and illumos compatibility layers for Linux are sketchy at best.

    For Linux laptops and home gamers, using XFS on a single HDD or SSD is fine, and even if you have a system with both HDDs and SSDs, tiered storage probably isn't of major benefit to you, because you don't have a workload that justifies it. A lot of people do, though, so they're either paying out the nose for way more SSD storage than they need, way more RAM than they need, way bigger servers than they need, ... or they're smart and they use ZoL.

    Comment


    • Originally posted by blackiwid View Post

      Of course when I speak about Users I speak about their own machines / Desktop, I don't go around and say hey "Linux" is on most computers because, it drives the Internet and all 10 quadrilliards of smartphones use it. The desktop is what matters and there Linux has like 2% or something und BSD like 0.1% if not less.
      Well.. yeah.. ? FreeBSD is a server OS.. so is Linux really (at least it use to be..) And ZFS is an enterprise filesystem.. It has some cool uses in the home but ZFS runs 100 petabyte arrays, ZFS dosen't compeate with Ext4.. it competes with NetApp's WAFL filesystem. People don't really want it in Linux tree as ryao has said. Most people are pretty happy with where it is.. they just want it to work well with Linux so they can use it to free their enterprise infrastructure from the likes of EMC, NetApp and DDN.

      Desktop is.. whatever floats your boat.

      Comment


      • Originally posted by ryao View Post
        As far as I know, Oracle was able to settle the lawsuit without giving very much. They did not want to divert resources from the Java lawsuit and Netapp did not want to be in the lawsuit. Netapp did get what they originally wanted though, which was not having to pay royalties over the ZFS patents.
        We are talking about legal here. As far as I know is not good enough. We need either Oracle or Netapp to state what was done in that settlement.

        Originally posted by ryao View Post
        There is no court higher than the US Supreme Court in the US according to the US constitution. It’s decisions are final. If you look at “international courts’” decisions, you would find the decisions are non-binding (and are often ignored by the losing parties).
        No this is the problem. International court rules on copyright are binding if they happen to be based on a trade agreements as breaching international trade agreements trigger international sanctions. By the way trade agreements signed off by the President of the USA has a higher authority than the US Supreme Court by the constitution. If Oracle if GPLv2 implied patent license gets ruled against in the International court and gets ruled in favour in the US court the result is Oracle can only sell product in the USA until they obey the GPLv2 implied patent license. The section of international law that creates GPLv2 implied patent license in fact automatically triggers International sanctions on the losing party no matter what they judge says.

        I will give you that there are many international court decisions that are not binding. Problem the ones that are binding from the international court hit hard. Yes is safer to take on GPLv3 declared patent license than end up in the international court because you are disputing if patents over rule copyright or copyright over rules patents. International court says copyright overrides patents and if you disagree with that point except not being able sell globally.

        Please note it would be highly unwise for the US supreme court different to the international court on GPLv2 implied patent license because the worst the international court could do is a full ban/International sanction on exports of a particular class of product from a particular country in the case of GPLv2 this would be all software that you buy with money from the USA. Basically death to the USA software industry.

        Basically international court is anywhere between completely toothless to I will kill you and everyone know just because I can. When comes to the implied patent license in copyright is the worst one. Yes it based on something that is a higher authority than the US Supreme court by US Constitution .

        https://en.wikipedia.org/wiki/Treaty_Clause
        Basically you are forgetting the effects of the Treaty Clause. And part of some treaties is that the case can be heard and rules in the international court with all countries agreeing to enforce the ruling. So technically with treaties over copyright that the USA has agreed to if Oracle was ruled against the USA would have to stop them from exporting and possibly everyone else in the paid for software field

        US Supreme court is not always the highest court in the USA. Treaty Clause at times put the international court above the US supreme court. GPLv2 is one of those horrible cases.


        Originally posted by ryao View Post
        We have the SFLC and plenty of companies willing to work together if there is an issue. Why do you think we have OpenZFS?
        Problem is you are not really reading what the SFLC people have told you. They gave you a lot of possible untested solutions and also told you without question CDDL and GPLv2 are incompatible.


        Originally posted by ryao View Post
        As for Oracle losing, they would lose if they went after ZFS too. That is what my legal counsel believes anyway.
        The reality is you have none of the documents/prior precedents you need to win for sure with CDDL. Has you legal counsel done a proper devil advocate test on your position.

        Reality once you do that on CDDL you find yourself in trouble. Devil advocate means you drop all the straw-man arguments that don't have proper backing.


        Originally posted by k1e0x View Post
        I'm convinced that the reason Oracle hasn't already gone after commercial implementations of OpenZFS already is that they would lose. They pay people 24/7 to look at issues like this.
        Really if Oracle currently sued the parties using ZFS and won there would be a good chance Oracle would spend more money fighting the legal case than they would get. So it does not make any sense at this time. This is one thing about Oracle case track record they go after people who they can make a profit from. So it makes perfect sense that Oracle will be sitting and waiting for ZFS.
        Last edited by oiaohm; 01-15-2020, 12:57 AM.

        Comment


        • Originally posted by allquixotic View Post
          the ability to efficiently use tiered storage.
          This is the problem.

          Originally posted by allquixotic View Post
          You would think that Linux would have a stable, mature, tested, highly optimized filesystem in-house for handling Tiered Storage properly, but it actually doesn't. Not at all. None of the solutions available with Btrfs, XFS, Ext4, LVM2, MD, and family even come close to the performance and feature-set of ZFS with tiered storage. Not to mention that the closest feature competitor, Btrfs, is still such a boondoggle stability-wise that Red Hat is abandoning it as a supported filesystem in RHEL. They also don't have any engineers to work on it, but if it were stable, they wouldn't need to.
          Now you are in trouble with logic. RHEL dropped Btrfs but did not give up on the idea of tiered storage.
          https://stratis-storage.github.io/faq/


          Originally posted by allquixotic View Post
          I will continue to use ZFS on Linux (at my own peril? Fine.) until Linux offers an in-kernel alternative that matches its performance, featureset and maturity. LLNL has the right idea -- they knew what they were doing when they invested so many dollars into the development of ZoL. They needed a tool that didn't exist, so they built one.
          To be correct is unlikely to be a complete in kernel alternative to ZFS. Its likely to be something like stratis.

          XFS lead developer has taken a different route to the tiered storage problem. Btrfs started as clone of the ZFS idea and ZFS started as something after the WAFL idea. All these have the idea that you integrate the block layer stuff into the file system layer.

          XFS developer route is more interesting. https://lwn.net/Articles/747633/ it starts here with a simple question. Why do I need a loopback device to mount a file system image in a file? the answer is it does not. One of the alterations of XFS was the means to pass though the blocks of a file to a file system driver without using a loopback. So over time all Linux file system drivers could be updated and render loopback useless.

          You have the enospace handling chnage. Something that is being worked on the means to see block level check-sums from general file system operations. Yes software raids do put checksums all all the blocks so do hardware raid controllers.

          There is a trend here.

          Why are so called tiered storage file systems reinventing the wheel? And is this right?

          Yes the wheel so called tiered storage file systems are all reinventing is the block layer. Maybe just Maybe we should improve the block layer API/ABI to file system so that all file systems Linux supports with min code can come tiered storage file systems.


          Originally posted by k1e0x View Post
          Well.. yeah.. ? FreeBSD is a server OS.. so is Linux really (at least it use to be..) And ZFS is an enterprise filesystem.. It has some cool uses in the home but ZFS runs 100 petabyte arrays, ZFS dosen't compeate with Ext4.. it competes with NetApp's WAFL filesystem. People don't really want it in Linux tree as ryao has said. Most people are pretty happy with where it is.. they just want it to work well with Linux so they can use it to free their enterprise infrastructure from the likes of EMC, NetApp and DDN.
          Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload. The Redhat/IBM backed route is interesting. In time we may remember ZFS as this biggest historic design mistake.

          Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.

          Comment


          • Originally posted by oiaohm View Post
            Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload. The Redhat/IBM backed route is interesting. In time we may remember ZFS as this biggest historic design mistake.

            Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.
            What are the design mistakes, That it wasn't written by RedHat? lol.

            You're such a shill oiaohm. Please stop.

            ZFS only changed how people thought about filesystems and moved the entire landscape to copy it. No filesystem created since hasn't taken inspiration from it. And XFS is trying -trying- to bolt on it's feature set. I've seen some of the hoops they are trying to do to make that happen and it's terrifying.. like loopback volumes and extents. ugh no thanks.

            Comment


            • Originally posted by oiaohm View Post
              Now you are in trouble with logic. RHEL dropped Btrfs but did not give up on the idea of tiered storage.
              I read about Stratis before. I actually like what Red Hat is doing. Unfortunately, Stratis right now is about as mature as ZFS was in 2002 or so. It has some years to go before it's ready for prime time. For those not eager to wait 3+ years, ZFS is the only option.

              If Stratis had been started, I don't know, in 2007, and already had 13 years of varied workload testing under its belt, ZFS on Linux might not even exist, because nobody would have bothered to port it. They'd be using Stratis with XFS.

              Now you might be saying "But wait, Stratis is layered on top of existing technologies, so it won't take 10 years to be ready." Maybe so -- I've seen successful "lightweight" projects that build on a combination of userspace and kernel primitives that hit the enterprise in a few years; Podman and LXD come to mind. But for people who use Ubuntu LTS or RHEL/CentOS releases only (for their stability and long support lifecycle), realistically those releases are not going to retroactively add in something like Stratis after release... probably. Or if they do, it will require a proprietary paid subscription until the next major release of the OS.

              Looks like RHEL 8 has Stratis as a "tech preview" -- that's all well and good, but tech previews generally would not get the Authority To Operate in a production environment. I might consider doing that on my home servers, but... it'd be like using LXD in Ubuntu 16.04. Rough around the edges. Plenty of gotchas and missing features. ZFS has none of these problems.

              Originally posted by oiaohm View Post
              XFS lead developer has taken a different route to the tiered storage problem. Btrfs started as clone of the ZFS idea and ZFS started as something after the WAFL idea. All these have the idea that you integrate the block layer stuff into the file system layer.
              I am aware of the technical reasons why it has been argued to keep the block layer and FS layer separate, and some of them are pretty compelling. But from what I've seen, this layering also creates performance problems with certain types of behaviors, and makes certain features extremely difficult to implement efficiently. If they can figure out how to keep these layers decoupled, or just very loosely coupled at best, while maintaining the same level of performance as a filesystem that tightly integrates block layer and FS layer concepts, great. But that's a development task, meaning it's probably months or years away from hitting Linux git master, and another couple years later until it's debugged, tested, and ready for enterprise distros to build on.


              Originally posted by oiaohm View Post
              Yes the wheel so called tiered storage file systems are all reinventing is the block layer. Maybe just Maybe we should improve the block layer API/ABI to file system so that all file systems Linux supports with min code can come tiered storage file systems.
              I think this is kind of the "Storage Spaces" idea from Windows. The closest equivalent Linux has today is LVM2, but that has a lot of problems, not the least of which is performance. Storage Spaces on Windows isn't a great implementation, either. It seems that whenever someone tries to implement a block layer that can handle tiered storage on its own, there are major limitations and performance gotchas, but whenever a filesystem tightly integrates the block and FS layers, it turns out great. Compare LVM2/Storage Spaces with ZFS/APFS. Which one is faster, least buggy, and more relied upon?

              The other problem is, to get this totally right and really nail down this problem, the block layer solution needs to be absolutely immaculate -- as in, perfect. It needs to be so good that any conceivable filesystem concept can use it. The only way the current block layer can be said to satisfy that criterion is because it's so feature-deprived that it literally implements the lowest common denominator, and is extremely simplistic in design. But it then puts a huge burden on filesystems to build on top of it for any non-trivial features, like tiered storage.


              Originally posted by oiaohm View Post
              Problem ZFS and WAFL in performance does not compete well with many file systems. Also no single file system is going to be perfect for every single workload.
              ZFS is fast enough for the people who use it. In fact, being able to take advantage of tiered storage probably results in a faster overall experience compared to having to directly write to the HDDs. Using ARC, L2ARC and ZIL when you have this kind of hardware (big HDDs + fast/small SSDs) will probably get you the highest total system performance (real-world, not microbenchmarked) for that given hardware. Obviously, for a single NVMe SSD in a laptop, a filesystem that doesn't do checksums like ext4, or one built for flash devices from the ground up like f2fs, will probably be faster.

              Originally posted by oiaohm View Post
              Please note saying that ZFS is a enterprise file system does not really mean much thinking that XFS is one of your oldest enterprise file systems. More interesting xfs leadership has had the least change out of any file system.
              Calling something enterprise doesn't make it stable. Having it run successfully in mission-critical applications on expensive hardware for many years without falling over, is what makes a filesystem earn the name "enterprise". I do believe XFS has also earned the moniker "enterprise" just like ZFS has, and that's totally fair. But XFS also does not compete with ZFS on features -- at least not by itself. Maybe in a few years, once Stratis is out of tech preview in RHEL 9 (??? maybe?) it will be a viable replacement for ZFS.

              Can you see the problem here? People have been needing to launch tiered storage solutions into production for years. Some people have said they've been using ZFS on Linux in production for almost 10 years now. And we're looking at maybe-possibly-soon (1 to 3 years) Linux coming up with some kind of an answer to tiered storage just now, in the early 2020s. Sure, hindsight is 20/20, and going forward with a green field project today the answer might be easier, but the need for tiered storage went unanswered by the mainline Linux developers and OS distros for many, many, many years, and ZoL filled the gap.

              ZoL will continue to fill that gap, until the Linux community at large settles on a proper solution.

              Comment


              • Stratus entire introduction was about how sad RedHat was it can't use ZFS due to licencing. (something that isn't true as Canonical has shown) and how btrfs sucks too much to develop. So they looped a bunch of technologies together in userspace and glued them together with dbus. I don't have a lot of faith for this. It has a lot of moving parts and they have to herd technologies heading in different directions. Gluster on ZVOLS seems far better.. and it works today.

                ZFS's development isn't on making it work.. it's on making it work better, faster and leveraging it in new ways.

                I wonder if RedHat even did a legal review on this outside the FSF lawyers? Or maybe they are one and the same? lol

                And the argument that the second largest Linux vendor "isn't big enough" for Oracle to sue doesn't hold water either from a company that will threaten to take you to court over a $5 Virtual Box license.
                Last edited by k1e0x; 01-15-2020, 03:23 AM.

                Comment


                • Originally posted by k1e0x View Post
                  And XFS is trying -trying- to bolt on it's feature set. I've seen some of the hoops they are trying to do to make that happen and it's terrifying.. like loopback volumes and extents. ugh no thanks.
                  There is a problem here what if XFS is not in fact bolting on new features but implementing old lost features xfs. This will come clear latter.

                  Originally posted by allquixotic View Post
                  Calling something enterprise doesn't make it stable. Having it run successfully in mission-critical applications on expensive hardware for many years without falling over, is what makes a filesystem earn the name "enterprise". I do believe XFS has also earned the moniker "enterprise" just like ZFS has, and that's totally fair. But XFS also does not compete with ZFS on features -- at least not by itself.
                  XFS was the first todo tiered storage but not by it self. IRIX xvm allowed to teired storage with XFS with ram drives we are talking before ZFS and WAFL was even a idea. When XFS was ported to Linux on top of LVM2 these features were lost.

                  In features XVM and XFS was a lot closer to ZFS than Stratis today. So a lot of what is happening to XFS today is implementing what the XVM/XFS combination had but now with a lvm2/xfs combination.

                  Originally posted by allquixotic View Post
                  The only way the current block layer can be said to satisfy that criterion is because it's so feature-deprived that it literally implements the lowest common denominator, and is extremely simplistic in design. But it then puts a huge burden on filesystems to build on top of it for any non-trivial features, like tiered storage.
                  This is absolutely correct. Lot of the block storage layers have been absolute crud.


                  Originally posted by allquixotic View Post
                  ZoL will continue to fill that gap, until the Linux community at large settles on a proper solution.
                  The reality here is sun put hell lot of marketing into ZFS the result was btrfs cloning ZFS way with no one really looking into what had been done before. By filling the gap people also did not have to look.

                  With ZoL license issues maybe the long term plan should be ZoL extermination.


                  Originally posted by k1e0x View Post
                  Stratus entire introduction was about how sad RedHat was it can't use ZFS due to licencing. (something that isn't true as Canonical has shown)
                  This is not a good point Canonical is in fact registered in the Isle of Man and Redhat is registered in the USA this makes quite a huge difference. Canonical goes ahead and disregards how USA courts might read CDDL and GPLv2 this may or may not come back and bite you but will not come back and bite Canonical. Linux Distributions are not created equal by legal liability.

                  Originally posted by k1e0x View Post
                  ZFS's development isn't on making it work.. it's on making it work better, faster and leveraging it in new ways.
                  This is exactly describing what the XFS lead developer is up-to as well.

                  Originally posted by k1e0x View Post
                  I wonder if RedHat even did a legal review on this outside the FSF lawyers? Or maybe they are one and the same?
                  Yes they did have reviews outside the FSF they had already done a set for MPL 1.1 because back in the day there was a kernel driver licensed under MPL 1.1 yes your CDDL is not different same problems exist in it as MPL 1.1.

                  Originally posted by k1e0x View Post
                  And the argument that the second largest Linux vendor "isn't big enough" for Oracle to sue
                  The odd of Oracle getting any money out of Canonical even if they win is almost zero due to the legal status of the Isle of Man. Correct answer from collectable money pool Canonical is not big enough for Oracle to go after. Redhat on the other hand would be.

                  Really its about time you stop bring out Canonical as why ZFS is safe. Canonical themselves are safe because of their country of registration. Anyone as like a end user in the USA or Australia if Oracle does sue is basically left holding the bag while Canonical walks away scott free. Lot of ways Canonical don't care about their customer liability only their own.

                  It would be better to target like Azure or AWS for ubuntu usage than go after Canonical over ZFS.

                  Comment


                  • Originally posted by oiaohm View Post
                    (red hat guy said stuff)
                    If old is good why not just improve UFS? It has the simplest block design ever. (they actually do improve it, they added snapshot support to it recently) The reason is this stuff needs to be designed from the ground up. And in filesystem land that takes 10 years minimum. They can't (shouldn't) horseshoe everything else on and expect everything to be ok.

                    End note there are a lot of good filesystems out there Linux (I mean redhat) could use and improve on if they don't like ZFS. bcachefs and HAMMER2 come to mind.. "But HAMMER is really ingrained into Dragonfly" Yes, it's is. So was ZFS in Solaris. They still ported it. This is hard work and RedHat always seems to take the easiest approach. Like them "fixing" the problem with the kernel OOM killer hanging the system by using a userland systemd daemon to make sure the kernel OOM killer is never called.. good job fixing that kernel Redhat! lol

                    I got to ask... do you really think you're going to end up with a good OS like this? This is why people are using FreeBSD.. because yes.. they implement things slower but they take their time and make sure it's engineered right. It's intentionally designed and changes are heavily debated, Linux randomly evolves with whatever is popular at the moment and whoever gets traction first.
                    Last edited by k1e0x; 01-15-2020, 04:27 AM.

                    Comment


                    • I am not a redhat guy you are just not liking my answers.

                      Originally posted by k1e0x View Post
                      If old is good why not just improve UFS? It has the simplest block design ever. (they actually do improve it, they added snapshot support to it recently) The reason is this stuff needs to be designed from the ground up. And in filesystem land that takes 10 years minimum. They can't (shouldn't) horseshoe everything else on and expect everything to be ok.
                      Really a lot of what XFS is doing is really not horseshoeing more on top of the file system. Its providing functions to get access to stuff hidden behind the file system. Like the blocks that a file is made up of for other usages other than direct io and so on.

                      Yes one of my questions is if XFS integration with the block layer behind it can be improved alot and make it more functional on tiered storage items like UFS most likely can be as well. UFS under LInux has had not had the backing from IBM providing servers and other things to test the file system to it limit.


                      Originally posted by k1e0x View Post
                      End note there are a lot of good filesystems out there Linux (I mean redhat) could use and improve on if they don't like ZFS.
                      The licensing of ZFS that fairly keep it out of the mainline kernel tree no matter who review of the license you read leave ZFS screwed for mainline Linux while it remains CDDL.

                      Please note stratis was not designed to be restricted to xfs only if a more suitable file system gets into mainline Linux. A suitablke file system has to be under a Linux kernel compatible license.


                      Originally posted by k1e0x View Post
                      bcachefs and HAMMER2 come to mind.. "But HAMMER is really ingrained into Dragonfly" Yes, it's is. So was ZFS in Solaris. They still ported it.
                      bachefs hopefully this year. The peer reviews of bcachefs to get into Linux kernel mainline has found many possible data eating errors will be fixed before merged. One thing to come out of btrfs mess was better general file system testing tools.

                      Some of ZFS issues with Linux is the fact its expecting the Solaris block layer that Linux does not really have. Hammer may be a very bad fit. Its one of the things the porting ZFS out of Solaris has caused some of ZFS performance problems.

                      Originally posted by k1e0x View Post
                      This is hard work and RedHat always seems to take the easiest approach. Like them "fixing" the problem with the kernel OOM killer hanging the system by using a userland systemd daemon to make sure the kernel OOM killer is never called.. good job fixing that kernel Redhat! lol
                      This problem comes about because of one particular difference between freebsd and Linux.
                      https://www.kernel.org/doc/Documenta...mit-accounting
                      Way more aggressive overcommit on Linux. One advantage of moving the OOM to userspace is the means to change it on the fly without rebuilding the kernel.

                      Originally posted by k1e0x View Post
                      I got to ask... do you really think you're going to end up with a good OS like this?
                      For this problem to allow means to use something Freebsd cannot do that gives Linux major advantages in particular workloads.

                      Originally posted by k1e0x View Post
                      This is why people are using FreeBSD.. because yes.. they implement things slower but they take their time and make sure it's engineered right. It's intentionally designed and changes are heavily debated, Linux randomly evolves with whatever is popular at the moment and whoever gets traction first.
                      This is also why FreeBSD lost the super computer market. Has also fall behind in the web server market. Never got a foothold in the mobile market.

                      Sorry trying to make out that FreeBSD has a strong position. People using FreeBSD for workloads are a dieing breed even with the havoc systemd caused.

                      Comment

                      Working...
                      X