Announcement

Collapse
No announcement yet.

Btrfs Async Buffered Writes Slated For Linux 6.1 - 2x Throughput Improvement

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

  • #81
    Originally posted by skeevy420 View Post

    There's nothing in that document that mentions containers or BTRFS. You keep citing that article and it doesn't say what you think it says. Nowhere in it does it back any of your arguments. All it backs up is that they have a distributed file system on a partitions for things like Search, Ads, and Newsfeed on servers in their Data Warehouse (see section 2.2 of the document you linked). That neither disproves nor proves anything about BTRFS.

    XFS has a max volume size of 8 Exabytes and while OpenZFS and BTRFS double that with 16 exabytes. BTRFS and OpenZFS can have double parity for the same amount of data that is single parity on XFS. I'd say that makes BTRFS and OpenZFS more exabyte scale than XFS.

    A regular user is someone like me who runs a standard top 20 Distrowatch desktop distribution and will get up and go to their day job when they get done posting on Phoronix after their morning coffee...which today will consist of installing custom-built steel hand rail on a deck...or I get to weld in the sun today...yay -S fuck-me. A regular user is not someone in the industry who will go to their programming, admin, tech support, etc job. I'll do that for a couple days where on Wednesday I get to go repair a fence where a corner post got hit by a truck at the cable company (two stretches of 6" industrial with 3 strands of barbed wire). I'll use quick-set concrete and do it all in one day. Sometime during all that I have an antenna showing up and I have to go do a gate operator repair. I'm really, really dreading Wednesday because jack hammering out the old post is going to fuck rotator cuff for a week or so and I'm just getting over the jack hammering for chain link fence I dug and installed last week. Just because I'm a bit of a roughneck doesn't mean I'm not into technology and FOSS.

    Is a 37yo general contractor in Arkansas a regular user enough for you?
    Yes, I would say your definition is pretty much spot on. So referring back to post #28... not at all related to Facebook... so stop using Facebook as a justification to run btrfs... the use cases are completely un-related.

    Unless perhaps this general contractor as everyone down to the apprentice running each individual app in a container for everything.

    With regards to your comment on xfs, you are correct its max volume size limit is smaller than btrfs, but you have clearly not read or understood that document. The premise of clustered file systems is that no one backing volume is ever particularly large, the cluster aggregates it all together into the one large primary clustered file system. The max volume size limit for either file system would be hugely difficult to reach.

    Perhaps King InuYasha can shed some light? What is the max single volume size for btrfs at Facebook? Anyone else in here run it past the multi-terabyte zone?
    Last edited by zexelon; 26 September 2022, 09:19 AM.

    Comment


    • #82
      IME it's almost impossible to lose data with btrfs. Even when doing really stupid shit like mounting it twice at the same time (in a VM with passed through disk, or mounting it while it's still mounted on a hibernated system) or when accidentally wiping a dirty bcache cache. In almost all cases "btrfs restore" will get your data back without issues. It's very reliable.

      Comment


      • #83
        Originally posted by zexelon View Post

        Yes, I would say your definition is pretty much spot on. So referring back to post #28... not at all related to Facebook... so stop using Facebook as a justification to run btrfs... the use cases are completely un-related.

        Unless perhaps this general contractor as everyone down to the apprentice running each individual app in a container for everything.
        Meta employs Zstd devs.
        Meta devs run Fedora on BTRFS on their workstations.
        Meta devs used Fedora's BTRFS root as one of the reasons to change from Ubuntu to Fedora & CentOS internally.
        Meta devs now run CentOS instead of Ubuntu on their servers.
        Meta sponsors a CentOS the Hyperscale SIG that adds BTRFS and related features to CentOS and provides disk images to install CentOS to a BTRFS root.
        CentOS does not support BTRFS without using the Hyperscale SIG.

        All the facts at hand justify using Meta/Facebook....and SUSE if you're hip to the know....as an anecdotal reason to use BTRFS. I'd be nice if there was a post from Meta that clearly stated it, but the facts that we do know heavily imply they use or plan to use a BTRFS root.

        Not yet. I'm not really into the whole container thing. Sometime this week I'll begrudgingly install Steam from Flatpak and it'll be the first time I'll install something in a container with an intent on running it long-term (not counting the times I ran Fedora Silverblue or AppImages). I'm tired of having to setup my Steam Library with every damn distribution install and would rather copy/paste some userdata into $HOME and be done with it.

        The part of me that notices weird things notices that you have both posts 28 and 82.

        Anyhoo, I have to go now. Y'all have a nice day.
        Last edited by skeevy420; 26 September 2022, 09:36 AM.

        Comment


        • #84
          Originally posted by coder View Post
          Is there any structural advantage either of those filesystems has to prevent "spontaneous corruption", or are you just butt-hurt from some prior bug in BTRFS?
          The structural advantage seems to be "not being BTRFS." It's taken so long and BTRFS still remains so buggy that I have to assume that there are deep structural reasons it will never be fixed. It's not hard to find evidence of this: How many *years* now has it been, with zero progress on the structural issue that make BRTFS raid fundamentally unusable?

          ZFS has an absolutely stellar reliability track record, and if bcachefs can achieve similar reliability despite being new,then we will know that the source BTRFS' troubles is simply being BTRFS.

          Comment


          • #85
            Originally posted by skeevy420 View Post

            Meta employs Zstd devs.
            Meta devs run Fedora on BTRFS on their workstations.
            Meta devs used Fedora's BTRFS root as one of the reasons to change from Ubuntu to Fedora & CentOS internally.
            Meta devs now run CentOS instead of Ubuntu on their servers.
            Meta sponsors a CentOS the Hyperscale SIG that adds BTRFS and related features to CentOS and provides disk images to install CentOS to a BTRFS root.
            CentOS does not support BTRFS without using the Hyperscale SIG.

            All the facts at hand justify using Meta/Facebook....and SUSE if you're hip to the know....as an anecdotal reason to use BTRFS. I'd be nice if there was a post from Meta that clearly stated it, but the facts that we do know heavily imply they use or plan to use a BTRFS root.

            Not yet. I'm not really into the whole container thing. Sometime this week I'll begrudgingly install Steam from Flatpak and it'll be the first time I'll install something in a container with an intent on running it long-term (not counting the times I ran Fedora Silverblue or AppImages). I'm tired of having to setup my Steam Library with every damn distribution install and would rather copy/paste some userdata into $HOME and be done with it.

            The part of me that notices weird things notices that you have both posts 28 and 82.

            Anyhoo, I have to go now. Y'all have a nice day.
            Yes, there is precious little primary information from Meta on the use of btrfs.

            I will now not be able to get the 28 / 82 thing out of my head all day, lol!

            Stay safe in the field today! Total respect for those that build in real life vs the digital life... even better for those that tinker in both!

            Comment


            • #86
              Originally posted by skeevy420 View Post

              Meta employs Zstd devs.
              Meta devs run Fedora on BTRFS on their workstations.
              Meta devs used Fedora's BTRFS root as one of the reasons to change from Ubuntu to Fedora & CentOS internally.
              Meta devs now run CentOS instead of Ubuntu on their servers.
              Meta sponsors a CentOS the Hyperscale SIG that adds BTRFS and related features to CentOS and provides disk images to install CentOS to a BTRFS root.
              CentOS does not support BTRFS without using the Hyperscale SIG.

              All the facts at hand justify using Meta/Facebook....and SUSE if you're hip to the know....as an anecdotal reason to use BTRFS. I'd be nice if there was a post from Meta that clearly stated it, but the facts that we do know heavily imply they use or plan to use a BTRFS root.

              Not yet. I'm not really into the whole container thing. Sometime this week I'll begrudgingly install Steam from Flatpak and it'll be the first time I'll install something in a container with an intent on running it long-term (not counting the times I ran Fedora Silverblue or AppImages). I'm tired of having to setup my Steam Library with every damn distribution install and would rather copy/paste some userdata into $HOME and be done with it.

              The part of me that notices weird things notices that you have both posts 28 and 82.

              Anyhoo, I have to go now. Y'all have a nice day.
              Afaik meta uses BTRFS in a very specific way, i.e. only with a small set of configurations (RAID 10?). For example its well known that BTRFS has RAID 5/6 issues for over a decade, ~2 years ago they finally added a warning in btrfs to display a warning making a BTRFS 5/6 partition

              Comment


              • #87
                Re Meta's usage of Btrfs, Chris Mason regularly states that Meta runs Btrfs on millions of servers (for instance, at the Btrfs BoF at LPC a few weeks ago).

                Comment


                • #88
                  Originally posted by stormcrow View Post

                  Ignoring stated problems with filesystems out of hand without investigation is stupid as are broad, sweeping statements of adequacy for each and every case imaginable. Facebook is using BTRFS because they have the expertise and 24/7 support structure to enable them to do so and respond to problems that their particular use case shows quickly. It doesn't immediately mean the use case is useful for all comers, especially people that are using it on commodity hardware. That last kicker is why ext4fs is 'over engineered' to a fault because of all of the corner case, gotchas, and outright screwiness of PC/consumer grade hardware. You might just dismiss that as a problem caused by hardware manufacturers, but the practical matter is that all hardware is capable of causing hiccups even with extremely good ECC from the RAM to the CPU out to the IO buses. BTRFS has historically been poor at anything Facebook itself doesn't use which has lead to data loss over the years. It's earned its reputation for being finicky. Use BTRFS without a fully staffed IT support team with developer support with caution. That's not FUD.
                  Bullshit, all of it, and case in point of someone just spreading FUD.

                  Comment


                  • #89
                    Originally posted by zexelon View Post
                    Facebook does not run btrfs on bare metal
                    Oh, but they do, and very much so.
                    ave a read: https://www.google.com/search?q=facebook+usage+of+btrfs

                    Comment


                    • #90
                      Originally posted by zexelon View Post
                      Does it even talk to a real block device instead of a virtual one?
                      LOL... Preposterous. And what would that change anyway?

                      Comment

                      Working...
                      X