Announcement

Collapse
No announcement yet.

Red Hat Appears To Be Abandoning Their Btrfs Hopes

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

  • #11
    Originally posted by duby229 View Post
    I'm pretty sure I sensed innuendo in there that Redhat was expressing interest in a new filesystem with the same intentions btrfs had. They more or less asked their customers to give them feedback on desires for features. That's where I think the innuendo is.
    RedHat wants to make a new filesystem? I'm not sure I understood the statements here.

    Comment


    • #12
      On a slightly relevant note, the first patches to close the RAID5/6 write hole have appeared on the mailing list of Btrfs, added by an OmNomNomNomracle dev.

      Comment


      • #13
        Originally posted by macemoneta View Post
        If it gets pulled from Fedora, I'll switch to another distribution before switching to another filesystem.
        I heard OpenSUSE is great for btrfs usage these days (hint hint).

        Comment


        • #14
          Other than the RAID5/6 issues, I'm not sure I understand the concerns. I started using BTRFS at home back around 2011-2012. A home system really isn't proof that the filesystem is ready for enterprise use... But now I have it on all my home desktop/laptop systems.

          On my home server as well as the server I have in a colo, I've been using BTRFS for years. All my servers utilize hardware RAID, but I definitely take big advantage of reflinks and snapshots. While I also run multiple VM's on both systems, I'm able to leave the CoW features on and get fine performance because I also use bcache.

          I've used bcache+BTRFS for years mostly without issue.

          Even my server usage doesn't really qualify as sufficient proof of enterprise readiness, but I think people are mostly concerned over perceived issues. Maybe the lack of solid/stable RAID5/6 is a large part of their concern. Oracle has been dog fooding BTRFS for at least a few years and there hasn't been any news of catastrophic failures.

          Back to bcache+BTRFS, I think it's worth clarifying the few issues I've had. I've lost some bcache+BTRFS partitions 2-3 times. Wasn't a HUGE deal because I have nightly backups to my other home server (FreeBSD+ZFS). However, the issue was due to the discard option in bcache. I don't think that this was necessarily either bcache or BTRFS, I suspect it was the state of the Linux discard code in general, which I believe Samsung had submitted patches for a few years back. Since switching off discard and using fstrim, it's been rock solid for years now. I think it very likely that the discard issues are fixed by now, but I think performing TRIM asynchronously with fstrim is the much better and more performant solution anyhow.

          Comment


          • #15
            Originally posted by starshipeleven View Post
            FYI: all Linux drivers are "use at your own risk", so is most opensource stuff.
            It's not like you can go and sue ext4 devs if your filesystem fucks up and eats your data, or AMD/NVIDIA if your GPU drivers crash and you lose a competitive Overwatch match for world championships or something.
            That is blatantly not true. Sure, many open-source drivers make no promises (because who can you point fingers at?) but closed source drivers aren't betas or "use at your own risk" unless specified otherwise. Red Hat focuses on enterprises, not gamers and home users, so they're more likely to use closed drivers. To my knowledge, RH also helps support many of the open-source drivers, at least common or basic ones like NICs or RAID controllers. Though maybe not officially established, the drivers are effectively stable, and RH customers have someone to go to in the event of a problem. This is partially what you're paying for.
            Even without RH's efforts, many open-source drivers are relatively simple and proven reliable. The performance and feature set of Btrfs changes frequently, for a filesystem.
            Btrfs is largely backed by Oracle, a company notorious for breaking compatibility. I get the impression RH doesn't assist in the development of Btrfs. If this is true, then they don't want to deal with the uncertainty of something so complex.

            Comment


            • #16
              Originally posted by starshipeleven View Post
              On a slightly relevant note, the first patches to close the RAID5/6 write hole have appeared on the mailing list of Btrfs, added by an OmNomNomNomracle dev.
              Yap, heard that on IRC this week. Finally.

              Comment


              • #17
                Originally posted by schmidtbag View Post
                That is blatantly not true.
                Here, read NVIDIA's blob license: https://www.geforce.com/drivers/license
                6.1 No Warranties. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. Without limiting the foregoing, you are solely responsible for determining and verifying that the SOFTWARE that you obtain and install is the appropriate version for your model of graphics controller board, operating system, and computer hardware.
                6.2 No Liability for Consequential Damages. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.



                And here a HP driver license (printer drivers, I don't know if they are for Linux or not) https://support.hp.com/us-en/document/c00581401


                9. DISCLAIMER OF WARRANTIES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, HP AND ITS SUPPLIERS PROVIDE THE SOFTWARE PRODUCT “AS IS” AND WITH ALL FAULTS, AND HEREBY DISCLAIM ALL OTHER WARRANTIES, DUTIES AND CONDITIONS, EITHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, WARRANTIES: (i) OF TITLE AND NON-INFRINGEMENT; (ii)OF MERCHANTABILITY; (iii) OF FITNESS FOR A PARTICULAR PURPOSE; (iv) THAT THE SOFTWARE PRODUCT WILL FUNCTION WITH NON-HP SUPPLIES OR ACCESSORIES; AND (iv) OF LACK OF VIRUSES ALL WITH REGARD TO THE SOFTWARE PRODUCT. Some states/jurisdictions do not allow exclusion of implied warranties or limitations on the duration of implied warranties, so the above disclaimer may not apply to you in its entirety.
                10. LIMITATION OF LIABILITY. Notwithstanding any damages that you might incur, the entire liability of HP and any of its suppliers under any provision of this EULA and your exclusive remedy for all of the foregoing shall be limited to the greater of the amount actually paid by you separately for the Software Product or U.S. $5.00. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL HP OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL INJURY, FOR LOSS OF PRIVACY ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE PRODUCT, OR OTHERWISE IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IF HP OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES AND EVEN IF THE REMEDY FAILS OF ITS ESSENTIAL PURPOSE. Some states/jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to you.


                Though maybe not officially established, the drivers are effectively stable, and RH customers have someone to go to in the event of a problem. This is partially what you're paying for.
                This part is correct.

                Even without RH's efforts, many open-source drivers are relatively simple and proven reliable. The performance and feature set of Btrfs changes frequently, for a filesystem.
                Huh? It's not like they don't have full control of what goes into their kernels didn't they?

                Btrfs is largely backed by Oracle, a company notorious for breaking compatibility.
                Yeah, also Facebook, and that evil monster Fujitsu. Man I'm sure I've also seen Chtulhu posting patches in the mailing list.

                I get the impression RH doesn't assist in the development of Btrfs.
                They have some guys on it too, by looking at the mailing lists.
                If this is true, then they don't want to deal with the uncertainty of something so complex.
                Knowing RedHat, it's probably because their average customer uses databases that have checksums already, or expendable webservers where it's irrelevant anyway.

                Comment


                • #18
                  Oracle is a purely self-serving, money-grubbing company. But they gain no financial, legal, public relations, or other benefit by making btrfs awful.

                  To add more anecdotes, I've got btrfs on seven drives in my house and I've never had a problem with it.

                  Comment


                  • #19
                    I remember a long time ago with kernel 3.18, the btrfs driver would crash the kernel within 10 seconds of a drive being mounted. Granted this was a big endian router but it still left a bad taste since x86 probably gets most of the testing.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      FYI: all Linux drivers are "use at your own risk", so is most opensource stuff.
                      It's not like you can go and sue ext4 devs if your filesystem fucks up and eats your data, or AMD/NVIDIA if your GPU drivers crash and you lose a competitive Overwatch match for world championships or something.
                      Nonsense, when you have a paid support contract from a vendor, Red Hat for example, they are on the hook for the quality of the product - that's what you are paying them for. That's what "support" means. It means that when it breaks, they are obligated to help you fix it.

                      They are not on the hook for your data of course. Or your availability. You are on your own hook for backups and redundancy. Your "eats your data" example is bogus, as that's not specific to open source software. The same is true for closed source software. Heck the same concept applies across just about every industry. If your BIC ball point pen fails during a final exam, and you fail the exam as a result, you can't win a lawsuit against BIC. At best, BIC owes you a new pen. If you're a taxi driver and your Michelin tire goes flat and you lose a fare, you can't win a lawsuit against Michelin. At best, Michelin owes you a new tire. Why are you trying to use this worldwide de facto standard of limited liability, and applying it to open source software as if that's a unique use case? A straw man argument if I ever heard one.
                      Last edited by torsionbar28; 01 August 2017, 03:17 PM.

                      Comment

                      Working...
                      X