Update on features not yet enabled by default: + RFE: kickstart option to control discard configuration https://bugzilla.redhat.com/show_bug.cgi?id=1860720 This can happen by using Anaconda kickstart argument '--fsoptions discard=async' which will add the mount option to /etc/fstab. Not decided is whether it's important enough of an optimization to do for Fedora 33, or make it opt-in for now and consider it by default for Fedora 34. Facebook has been using it in production for > 6 months, it's solved many problems with no regressions. Fedora already enables weekly fstrim via fstrim.timer by default. The advantage of 'discard=async' is mainly for workloads with heavy writes and deletes. Once per week fstrim might not be frequent enough. Both fstrim and discard=async mount option can peacefully co-exist. + RFE: enable compression on btrfs installs https://bugzilla.redhat.com/show_bug.cgi?id=1851276 Btrfs offers two ways to enable compression: a mount option with granular level (amount of compression); an XATTR that can be set per subvolume, directory or file. Further there is a NOCOMPRESS flag that could be set to selectively inhibit either of the prior two on a per subvolume, directory or file basis. The current idea is use kickstart argument '--fsoptions compress=zstd:1' to enable compression file system wide with the "least effort" compression level; and a kickstart %post script to 'btrfs property set -ti /home compression none' to disable compression on /home. Why? This isolates compression to system related things. While most systems are expected to see performance improvement due to compression and decompression reducing read and write latency, any write performance hit would be limited to system writes which are generally inconsequential: certain logs, configuration files, rpm+dnf+PackageKit databases, and binaries during system updates. And this also leaves it up to desktop integration for user selected compression. Caveat? New subvolumes created in ~/home will not inherit this no compression flag. New subvolumes will be compressed by default (so long as the compress mount option is set). Also, it's not obvious what is and isn't compressed. UI/UX in this area is limited. Improvements are planned, but not in the Fedora 33 release time frame. There is a 'compsize' package in Fedora (all releases) that can show compression information on directories and files. It's not difficult for folks to opt in to both of these features if we don't enable them by default in Fedora 33. In fact you can opt in now with F31, F32, and F33. However, it is more difficult to figure out a way, and commit, to enabling these features on upgrades from F32/F33->F34. Documentation: + LVM to Btrfs secret decoder ring https://fedoraproject.org/wiki/User:Chrismurphy/lvm2btrfs This isn't brand new but not previously shared in these updates. The LVM to Btrfs idea is Langdon's. Calling it a secret decoder ring is my idea because I'm a kid. And it's funny because this all open source so it's not a secret. :D Ahh so easily amused. What this needs, besides organizing and formatting, are use cases. General purpose (common) use cases get higher priority than the obscure. Feel free to reply to this email, or directly edit the wiki and add use cases at the bottom. Advantage to no formatting? You don't have to format your use case! Idea is to move this into Quick Docs. + Would it be useful to have a single reliable landing page for Btrfs resources? https://fedoraproject.org/wiki/Btrfs This is a bit stale. And in the context of Btrfs by default I think it'd be more useful as a landing page of some sort. Make it like an index or a FAQ, and link to the actual resource. For example, the secret decoder ring! Any ideas about this are welcome. Fixes: + armhfp desktop images are building again, and now have Btrfs enabled by default. Testing appreciated! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
