Announcement

Collapse
No announcement yet.

Fedora 34 Cleared For Btrfs Zstd Compression By Default, DNF/RPM Copy-On-Write

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

  • Fedora 34 Cleared For Btrfs Zstd Compression By Default, DNF/RPM Copy-On-Write

    Phoronix: Fedora 34 Cleared For Btrfs Zstd Compression By Default, DNF/RPM Copy-On-Write

    The Fedora Engineering and Steering Committee has unanimously approved several high profile features for the upcoming Fedora 34...

    http://www.phoronix.com/scan.php?pag...mpress-DNF-CoW

  • #2
    Is there actually something _wrong_ with XEmacs? I'm not a fan of deprecating things just because they aren't getting new features added. I haven't seen any new features added to "cat", "echo", or "true" lately, but that's no reason to deprecate them.

    Comment


    • #3
      Originally posted by brouhaha View Post
      Is there actually something _wrong_ with XEmacs? I'm not a fan of deprecating things just because they aren't getting new features added. I haven't seen any new features added to "cat", "echo", or "true" lately, but that's no reason to deprecate them.
      Unlike those coreutils, XEmacs is a huge codebase with multiple add-ons.

      https://fedoraproject.org/wiki/Changes/Deprecate_xemacs

      The current maintainer who was also an upstream developer doesn't want to deal with. If anyone else wants to volunteer to take over, they can. Nothing is stopping that.

      Comment


      • #4
        btrfs, because of its copy-on-write nature, is a filesystem that was a very high file fragmentation ratio compared to non-COW filesystems when overwriting a portion of an already existing file. Unfortunately, the mount option "nodatacow" implies nodatasum and disables compression - so, basically, nodatacow is a pointless btrfs option because of its implications.

        Comment


        • #5
          Originally posted by atomsymbol View Post
          btrfs, because of its copy-on-write nature, is a filesystem that was a very high file fragmentation ratio compared to non-COW filesystems when overwriting a portion of an already existing file. Unfortunately, the mount option "nodatacow" implies nodatasum and disables compression - so, basically, nodatacow is a pointless btrfs option because of its implications.
          I would say it has it uses given the well known tradeoffs. For something like a disk cache, those tradeoffs are very well serviceable.

          Comment


          • #6
            any grub changes yet related to booting from snapshots?
            Last edited by horizonbrave; 19 January 2021, 09:24 PM.

            Comment


            • #7
              Link to discussion on Fedora's Fedora Engineering Steering Committee (FESCo) tracker. Link to discussion on devel mailing list. Looks like they will be defaulting to installing with compress=zstd:1.

              Comment


              • #8
                Originally posted by Phoronix
                package installation atop Btrfs in CoW mode. This should provide for faster package installations and upgrades
                Oddly enough, CoW not necessarily is faster than creating a new file. At least when dealing with small-sized ones, which would be the case for package installations.

                Incidentally, yesterday I benchmarked ccache with and without CoW (they added an opt-in feature to use reflinks instead of copying files). What I found is that building a libinput with reflinks is consistently 30% slower than building without.

                I should also mention that I asked question about that on #btrfs IRC channel, but nobody replied.

                upd: apparently something was fixed in between 5.10.4 and 5.10.9 kernels: upon re-running the benchmark after having upgraded to the latter there's no difference anymore with or without reflinks build.
                Last edited by Hi-Angel; 20 January 2021, 05:04 PM.

                Comment


                • #9
                  Originally posted by Hi-Angel View Post

                  Oddly enough, CoW not necessarily is faster than creating a new file. At least when dealing with small-sized ones, which would be the case for package installations.

                  Incidentally, yesterday I benchmarked ccache with and without CoW (they added an opt-in feature to use reflinks instead of copying files). What I found is that building a libinput with reflinks is consistently 30% slower than building without.

                  I should also mention that I asked question about that on #btrfs IRC channel, but nobody replied.
                  WTF? I didn't expect that...
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10
                    Originally posted by darkbasic View Post

                    WTF? I didn't expect that...
                    Exactly my thoughts. Although, as I mentioned in the results I use 5.10.4, and Phoronix mentioned BTRFS had some performance regression fixed in 5.10.8. I should maybe update and retest, but I doubt it would change anything because AFAIK the regression had nothing to do with reflinks.

                    Comment

                    Working...
                    X