Announcement

Collapse
No announcement yet.

Btrfs Gets Fixes & Prep Work In Linux 4.14

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

  • Btrfs Gets Fixes & Prep Work In Linux 4.14

    Phoronix: Btrfs Gets Fixes & Prep Work In Linux 4.14

    Besides the separate pull request that brought Zstd compression support for Btrfs with the in-development Linux 4.14 kernel, the main Btrfs pull request was also submitted on Friday for updating this Linux file-system...

    http://www.phoronix.com/scan.php?pag...rfs-Linux-4.14

  • #2
    A few weeks ago I was reading an article here that Btrfs is losing it's ground and another (how many do we need?) will replace it. Is this still true? Btrfs works perfectly here, is getting fixes and although ZFS has many good looking features it isn't included in the kernel and basically requires ECC.

    Comment


    • #3
      Originally posted by archie2016 View Post
      A few weeks ago I was reading an article here that Btrfs is losing it's ground and another (how many do we need?) will replace it. Is this still true? Btrfs works perfectly here, is getting fixes and although ZFS has many good looking features it isn't included in the kernel and basically requires ECC.
      No source?

      Comment


      • #4
        Originally posted by archie2016 View Post
        A few weeks ago I was reading an article here that Btrfs is losing it's ground and another (how many do we need?) will replace it. Is this still true? Btrfs works perfectly here, is getting fixes and although ZFS has many good looking features it isn't included in the kernel and basically requires ECC.
        What do you mean? Because Red Hat won't support it anymore? Well, because they just don't have the expertise to do it. They develop indeed a tool set based on XFS which will have Btrfs like features.

        Sadly, you can't use Btrfs anywhere, because it has a bad performance for databases and VMs. The performance will improve if you disable COW, but I don't know how this will impact its features. Maybe someone can answer that.

        Comment


        • #5
          Is btrfs receiving the patch fixing the write hole in raid 5/6?

          Comment


          • #6
            Originally posted by starshipeleven View Post
            No source?
            https://www.phoronix.com/scan.php?pa...es-Btrfs-Again

            Comment


            • #7
              Originally posted by Steffo View Post
              The performance will improve if you disable COW, but I don't know how this will impact its features. Maybe someone can answer that.
              That disables checksumming too.

              Comment


              • #8
                Originally posted by thelongdivider View Post
                Is btrfs receiving the patch fixing the write hole in raid 5/6?
                no, it's still being worked on (currently the patch on the mailing list that closes the write hole requires a separate journal drive).

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  That disables checksumming too.
                  But this is necessary in order to correct flipped bits, right?

                  Comment


                  • #10
                    Originally posted by Steffo View Post
                    But this is necessary in order to correct flipped bits, right?
                    Yes, without checksumming there is no data protection from flipped bits.
                    The checksumming can't work without COW.
                    Iif you disable COW and you have a failed I/O or something, then the file was modified (probably corrupted now) while metadata (and checksums) were not changed yet. (as metadata and checksums are updated after the data was moved).

                    ZFS has the same general issue (look up "disabling ZIL" which is the journal-like thing it uses to be COW), that's how COW filesystems work.

                    ZFS sidesteps the lower performance in databases and VMs by using a "SLOG", which is basically using a fast SSD cache drive. This removes the need to disable the ZIL (and end in the same situation as btrfs without COW), as now most of your writes will go on the SSD and wait there until the array has fully written them before being deleted.
                    It will eventually murder the SSD, but that's not a major issue.

                    Btrfs has no native caching system like that (people use external caching like bcache, which isn't power-failure safe though).
                    When they implement some kind of half-decent native caching there won't be need to disable COW for those loads (if you have set up this cache anyway).
                    Last edited by starshipeleven; 09-09-2017, 11:33 AM.

                    Comment

                    Working...
                    X