Announcement

Collapse
No announcement yet.

Btrfs Finally Has A Concise Status Page

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

  • Btrfs Finally Has A Concise Status Page

    Phoronix: Btrfs Finally Has A Concise Status Page

    The Btrfs file-system finally has a concise status page so users can quickly and easily know the status of various features...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The quota + subvolume is buggy, mostly for diff backup and subvolume removing
    Compression: mostly OK: it's a base for me
    Free space tree: buggy on x86_64 with subvolume for backup diff, mostly on low space
    Last edited by alpha_one_x86; 12 September 2016, 05:07 PM.
    Developer of Ultracopier/CatchChallenger and CEO of Confiared

    Comment


    • #3
      Originally posted by alpha_one_x86 View Post
      The quota + subvolume is buggy, mostly for diff backup and subvolume removing
      Compression: mostly OK: it's a base for me
      Free space tree: buggy on x86_64 with subvolume for backup diff, mostly on low space
      I hope you have posted this on the btrfs mailing list as well and that the "bugreport" is not just here on Phoronix

      http://www.dirtcellar.net

      Comment


      • #4
        Hmmm, if I look at send, it says OK, and then goes on to say it is not ok but mostly OK (corner cases means mostly OK, and not OK).
        And it is disturbing that (re)balance is on the TBD. Without that btrfs is going to hopelessly fill up with meta data.
        So, again, it was more whishful, than actual concise.
        I also miss some features like online dedup. And I see that batch dedup also should not be used, which would have made the mostly OK with defrag just a plain OK.

        Comment


        • #5
          It's pretty sad Ceph relies on this immature garbage.

          Comment


          • #6
            status: still buggy and slow

            Comment


            • #7
              Originally posted by anarki2 View Post
              It's pretty sad Ceph relies on this immature garbage.
              Looking at the Ceph docs it seems that they now recommend XFS for production and no longer recommend btrfs even for development and testing.

              Comment


              • #8
                Originally posted by anarki2 View Post
                It's pretty sad Ceph relies on this immature garbage.
                nobody use btrfs with ceph in production. Recommended FS is XFS.

                And they are going to not use any filesystem at all with the new bluestore backend.

                BlueStore: a new, faster storage backend for Ceph - Download as a PDF or view online for free

                Comment


                • #9
                  Originally posted by peppercats View Post
                  status: still buggy and slow
                  Confirmed, and +1

                  What I didn't like about btrfs from the start was the developer's motto: "If a feature takes us 80% there, then it's OK"...or something like that.
                  Well all the filesystem feels like it's 80% done now.

                  Comment


                  • #10
                    This kind of sums it up all for me:
                    ABOUT DATA COUNCIL: Data Council (https://www.datacouncil.ai/) is a community and conference series that provides data professionals with the learning and ne...


                    and here is Kent Overstreet's take on it (which I completely agree - https://goo.gl/U0UFfN ): "btrfs, which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future filesystems because too many people were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times and had to switch at the last minute, and server vendors who years ago hoped to one day roll out btrfs are now quietly migrating to xfs instead)."


                    Comment

                    Working...
                    X