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

[phoronix]

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?page=news_item&px=Fedora-34-Compress-DNF-CoW

[brouhaha]

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.

[RahulSundaram]

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.

[RahulSundaram]

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.

[horizonbrave]

any grub changes yet related to booting from snapshots?

[aorth]

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.

[Hi-Angel]

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.

[darkbasic]

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...

[Hi-Angel]

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.

[Hi-Angel]

darkbasic I just upgraded to 5.10.9 kernel, and I can tell indeed apparently something was fixed, because results are changed. Now I see no difference in time or CPU usage when I build libinput with or without reflinks being used.