https://fedoraproject.org/wiki/Changes/Ignore_Anaconda_kernel_boot_paramete…
== Summary ==
Right now Anaconda allows usage of boot options both with the 'inst' prefix
(inst.stage2=) and without (stage2=). We would like to ignore the use of
Anaconda kernel boot parameters which do not contain the 'inst.' prefix.
== Owner ==
* Name: [[User:jkonecny| Jiří Konečný]]
* Email: <jkonecny(a)redhat.com>
== Detailed Description ==
Anaconda allows you to use kernel boot parameters with and without the
'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying
boot parameters without the 'inst' prefix has not been recommended for
years and has been deprecated since Fedora 33. We (Anaconda team) would
like to make it an official requirement now that users must specify the
'inst.' prefix all the time.
The reason for this is frequent parameter conflicts with other projects. We
already had a few issues with conflicts in the past, such as if the user
ran an installation with `debug`. In that case the installation boot would
enable debug mode for the kernel and also for Anaconda which is probably
not what the user intended.
Another reason is to make it readable at first glance what belongs to
Dracut (rd.), kernel (no prefix) or Anaconda (inst.).
== Feedback ==
We have sent mail about doing the deprecation on Fedora 33. The only issue
there was why the prefix is 'inst.' and not 'anaconda.'.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Benefit to Fedora ==
This change should make crystal clear what kernel boot parameters are
processed by the Anaconda installer.
It will also avoid conflicts with other kernel boot parameters.
== Scope ==
* Proposal owners: Remove support to process arguments without the 'inst.'
prefix and require the 'inst.' prefix for kernel boot parameters consumed
by Anaconda.
* Other developers:
All configurations using the not-recommended solution without prefix will
have to change the invocation of the kernel boot options consumed by
Anaconda. These users are already warned since Fedora 33 after boot.
This should not be a problem for ISOs we ship because they already use the
recommended 'inst.' prefix everywhere. However, it will probably touch some
custom PXE configurations and other custom ISO configurations which are
prone to this, because users often want to save typing and not explicitly
write the 'inst.' prefix. Fortunately, most of these configuration changes
shouldn't be that hard to change.
* Release engineering: [https://pagure.io/releng/issue/9889 #9889]
* Policies and guidelines: This should not be required. All the
documentation should use the recommended 'inst.' prefix already.
* Trademark approval: No (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
If your custom infra configuration is not updated then new Fedora
installations could not install correctly. Most probably the ISO will not
boot (use of 'stage2=') or your repositories won't be used (use of 'repo=').
== How To Test ==
# You need a Virtual Machine and ISO for testing.
# Boot the installation using the ISO and try Anaconda specific kernel boot
parameters. See here to find out the list
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html.
# Parameters without the prefix should be ignored and with the prefix
should be used.
== User Experience ==
Users of Fedora official ISOs should not be impacted because all the Fedora
official ISOs should already use the recommended prefix.
== Dependencies ==
Don't know about any packages impacted by this change.
== Contingency Plan ==
* Contingency mechanism: The Anaconda team will revert code changes and get
back support for boot parameters without the 'inst.' prefix.
* Contingency deadline: Final Freeze
* Blocks release? No
* Blocks product? This won't require changes for any specific product.
== Documentation ==
I don't think we need to document this change other than in Release Notes.
As mentioned before, the solution without 'inst.' prefix has not been
recommended for years and it should not be used anywhere in the official
documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Here we are, already thinking about Change submission deadlines for
Fedora 34! Some key dates you should know:
* 2020-12-16 — Change proposal deadline: Changes requiring
infrastructure changes
* 2020-12-29 — Change proposal deadline: System-Wide Changes, Changes
requiring mass rebuild
* 2021-01-19 — Change proposal deadline: Self-Contained Changes
The full Fedora 34 schedule is on Fedora People:
https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
I will send additional reminders as we approach the deadlines. You can
also read the weekly Fedora program updates on the Community Blog[2]
or join the FPgM office hours at 9 AM Eastern (currently 1400 UTC) on
Wednesdays[3].
[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://communityblog.fedoraproject.org/category/program-management/
[3] https://apps.fedoraproject.org/calendar/meeting/9527/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages
on your own, please do so before Dec 14, which is when I will begin
doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
https://fedoraproject.org/wiki/Changes/Deprecate_xemacs
== Summary ==
Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and
neXtaw packages, all of which have dead upstreams.
== Owner ==
* Name: [[User:jjames|Jerry James]]
* Email: loganjerry(a)gmail.com
== Detailed Description ==
I have been part of XEmacs upstream for over 20 years, and have
maintained the Fedora package for over 11 years. Upstream development
had already slowed significantly when I became Fedora maintainer. The
last release was over 7 years ago. Since that time, development has
essentially come to a halt. Somebody will push a commit every now and
then, but significant bugs are not being fixed. I see no future for
the project. We should start moving towards dropping it from the
distribution. The upstream sources have been spread across 3 packages
in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra.
In addition, the xemacs package uses an ancient, unmaintained 3D X
library: neXtaw. It's last release was in 2003. Since xemacs is the
only package in Fedora that uses neXtaw, I propose that it also be
deprecated so we can eventually drop it.
Deprecation is warranted because there are about a dozen XEmacs add-on
packages in Fedora. This will prevent us from adding any more as we
work to retire the existing add-ons.
== Feedback ==
On December 7, 2020, I
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
communicated my intent to file this Change] on fedora-devel-list.
There has been no community feedback.
== Benefit to Fedora ==
This Change will open a path for us to eventually remove unmaintained
software from the distribution.
== Scope ==
* Proposal owners:
The only required work is the addition of `Provides: deprecated()` to
the 4 affected packages.
* Other developers:
No immediate work is required. Eventually, maintainers of XEmacs
add-on packages will need to retire those packages so that XEmacs
itself can be retired.
* Release engineering:
This change does not require coordination with or impact release
engineering and does not require a mass rebuild.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
While this proposal does not match any of the
[https://docs.fedoraproject.org/en-US/project/objectives current
objectives], it is not opposed to any.
== Upgrade/compatibility impact ==
Since the Change only deprecates packages, it has no immediate effect
on upgrades or compatibility. Eventually, when the affected packages
are retired, fedora-obsolete-packages will be updated to properly
manage upgrades.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
This change will not lead to any immediate changes in user experience.
Eventually, we will retire the affected packages, which will impact
users of those packages. We will seek to communicate the upcoming
retirement as we work towards it.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? None
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw
packages have been deprecated. XEmacs users should prepare for the
eventual removal of these packages from the Fedora distribution.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/xfce-4.16
== Summary ==
Xfce 4.16 is a stable release with proven components, provide features
to both new and power users alike. This change proposal is submitted
to sync fedora packages with the latest upstream release.
== Owners ==
* Name: [[User:nonamedotc| Mukundan Ragavan]]
* Email: nonamedotc(a)fedoraproject.org
* Name: [[User:kevin| Kevin Fenzi]]
* Email: kevin(a)scrye.com
== Detailed Description ==
This change migrates Xfce desktop environment (DE) to the latest
version provided by upstream developers. This release brings, amongst
others, the following features
* client-side decorations
* fractional scaling
* new status tray plugins
* Streamlined application chooser (i.e. merged "mime type editor" and
"default applications")
Full feature list can be viewed at [https://xfce.org/about/news Xfce news]
== Benefit to Fedora ==
Updating Xfce to 4.16 will provide Fedora Xfce users stable but latest
versions of upstream software. We will also be able to provide timely
bug fixes.
== Scope ==
* Proposal owners:
** Update core xfce packages to 4.16
** Rebuild plugins once core packages are build
* Other developers: N/A (not a System Wide Change)
* Release engineering: <!-- [https://pagure.io/releng/issue/7647 #7647]
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
* A fresh install should have fully functional Xfce DE
* Upgrade from Fedora 33 or older should be mostly seamless
** Users will notice differences in certain instances (e.g. settings)
because of implementation of client side decorations
** Default ALT+TAB behavior will likely be different.
No special configuration or hardware needed.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 34 ships with Xfce 4.16.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
== Summary ==
This change makes the GRUB configuration files layout to be consistent
across all the supported architectures. Currently EFI is a special
case since the GRUB configuration file and environment variables block
are stored in the EFI System Partition (ESP) instead of the boot
partition (or `/boot` directory if no boot partition is used).
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm(a)redhat.com
* Name: [[User:Gicmo|Christian Kellner]]
* Email: ckellner(a)redhat.com
== Detailed Description ==
The GRUB configuration files layout on EFI platforms is not consistent
with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le
with Open Firmware). On platforms using EFI the GRUB configuration
file (`grub.cfg`) and environment variables block (`grubenv`) are
stored in the EFI System Partition (ESP) while for non-EFI platforms
these are stored in the boot partition (or `/boot` directory if not
boot partition is used).
The reason for this is that the path where the GRUB bootloader
searches for its configuration file varies depending on the firmware
interface used. In most cases, GRUB searches for it in the path set in
the `$prefix` variable. The device is not specified in that case, GRUB
just searches for a configuration in this path for every detected
device. But on EFI, a special `$fw_path` variable is used instead.
This variable specifies both the device and path from where the GRUB
bootloader was loaded and these are used to search for the
configuration file. This is done for security reasons, to make sure
that the correct GRUB configuration file is used and not just the
first one found in one of the detected devices.
Since the GRUB binary is located in the ESP, it expects to find the
configuration file in that location as well. But this creates the
mentioned inconsistency, because the GRUB configuration file has to be
stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms
it has to be stored in `/boot/grub2/grub.cfg`.
This leads to a GRUB configuration layout that is confusing for users
and error prone, since either the tools that are used to manage these
files have to be aware of the differences or symbolic links used to
hide the fact that the pats differ depending on the platform. Also, it
creates artificial constraints on the OS installation due the
differences in the configuration layout used. A system installed when
using EFI won't be bootable if the firmware configuration is changed
to boot using legacy BIOS instead, for example enabling the EFI
Compatibility Support Module or moving the disk to a BIOS machine.
The proposal is to always store the `grub.cfg` and `grubenv` files in
the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg`
to only be a small configuration file that sets a different `$prefix`
variable and loads the configuration file stored in
`/boot/grub2/grub.cfg`.
The `$prefix` variable will be set to the device partition where
`/boot/grub2/grub.cfg` is stored, using the partition filesystem's
Universally Unique IDentifier (UUID). That way the correct GRUB
configuration file will be loaded, making it as secure as the current
approach where the configuration file in the ESP is used.
A drawback of the new approach is that the GRUB configuration will now
depend on the boot partition (or `/boot` directory if no boot
partition is used). But since the kernel and initramfs images are
stored there too, the bootloader configuration already has this
dependency anyways.
Note that the proposed configuration files layout is already used by
the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this
will make the systems installed with Anaconda to be consistent with
the images generated by these.
== Benefit to Fedora ==
This change will not only simplify and make less confusing the GRUB
configuration but also allow the following improvements:
* To have a consistent configuration across all the architectures using GRUB.
* Allow the same installation to be booted with either EFI or legacy BIOS.
* Use the same documentation and commands for all architectures
instead of having EFI as a special case.
* Make GRUB configuration tools more robust by not relying on symbolic
links to be created and not having to handle platform specific cases.
* Align with images generated by COSA and OSBuild on how the GRUB
configuration files are used.
* Align with other Linux distributions on how the GRUB configuration
files are used.
== Scope ==
* Proposal owners:
** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in
`/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms.
** Make Anaconda to generate the minimal GRUB config file in the ESP
that sets the `$prefix` variable and loads the configuration file
located in `/boot/grub2/grub.cfg`.
** Modify the grub2 package scriptlets to not generate the
`/boot/grub2/grubenv` and `/etc/grub2-efi.cfg` symbolic links since
these will not be needed anymore.
** Make any changes needed in tools that use these configuration files
(`grubby`, `kernel-install` scripts, etc).
* Other developers:
** The Anaconda developers will need to review and merge the patches
to change where the GRUB configuration files are created.
** Test and watch for regressions.
* Release engineering:
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
The changes will only be for new installations, existing systems will
not be impacted and will continue using the grub.cfg and grubenv files
that are located in the ESP.
== How To Test ==
* Install Fedora 34 and verify that the GRUB configuration is correct.
* Check that the `/boot/efi/EFI/fedora/grub{.cfg,env}` files are not present.
* Check that the `/boot/grub2/grub{.cfg,env}` files are present.
* Enter the GRUB prompt by pressing 'c' from the GRUB boot menu and
execute the following command:
<pre>echo $prefix</pre>
and verify that the prefix is set to the partition that contains the
`/boot/grub2` directory.
* Re-generate the GRUB configuration file with:
<pre>grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
and verify that the GRUB configuration is still correct.
== User Experience ==
No visible changes are expected other than the configuration files
being present in a different path. This should improve the overall
user experience.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the Anaconda and grub2 package
scriptlets changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
* Fedora CoreOS assembler script that creates the GRUB config file for
EFI: https://github.com/coreos/coreos-assembler/blob/master/src/create_disk.sh
* OSBuild org.osbuild.grub2 stage that creates the GRUB config file
for EFI: https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.grub2
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags. This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.
== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: law(a)redhat.com
== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file. This should significantly
improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects. If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.
== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages. This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set. Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.
* Other developers: There should be minimal work for other
developers. The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles. We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed. This work may expose more of
these problems.
I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.
== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility. In
fact, the change should have no user visible impacts.
== How To Test ==
No special testing is needed. Any issues with this proposal will show
up as FTBFS issues.
== User Experience ==
Users should see no changes to the user experience.
== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.
== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files. So no special contingency
mechanism should be needed
* Contingency deadline: It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes ==
I do not expect this change to require any release notes.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/IBus_1.5.24
== Summary ==
IBus will use the mmap(2) feature to show emoji and Unicode tables in
order to reduce the physical memory usage.
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
Currently IBus disables the emoji and Unicode features in some system
users likes gdm, liveuser, gnome-initial-setup not to exhaust the
limited memory usage with LiveDVD. The emoji data requires about 10MB
and the Unicode data requires about 15MB and the total 25MB is
required roughly to show the tables. The Fedora testers ask to test
the emoji feature and Unicode feature in LiveDVD and the next IBus
will use mmap to be available the emoji and Unicode data with
liveuser.
== Feedback ==
Fedora I18N testers asks to test the emoji and Unicode data without
installing Fedora to disc.
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
About 25MB free disc space will be needed.
== How To Test ==
# Run Fedora LiveDVD and log into the Fedora desktop
# Run `gnome-control-center region` and add both XKB and input method
sources. E.g. "English (US)" and "Hangul"
# Enable an XKB source with mouse or Super-space shortcut key. E.g.
"English (US)"
# Type Ctrl-Shift-e, "smile", space, and Enter key.
U+1F603 is output.
== User Experience ==
The physical memory usage will be reduced.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the change to IBus.
* Contingency deadline: Beta release
* Blocks release? No
* Blocks product? None
== Documentation ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
== Summary ==
On variants using btrfs as the default filesystem, enable transparent
compression using zstd. Compression saves space and can significantly
increase the lifespan of flash-based media by reducing write
amplification. It can also increase read and write performance.
== Owners ==
* Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide
Cavalca]], [[User:josef|Josef Bacik]]
* Email: michel(a)michel-slm.name, dcavalca(a)fb.com, josef(a)toxicpanda.com
== Detailed description ==
Transparent compression is a btrfs feature that allows a btrfs
filesystem to apply compression on a per-file basis. Of the three
supported algorithms, zstd is the one with the best compression speed
and ratio. Enabling compression saves space, but it also reduces write
amplification, which is important for SSDs. Depending on the workload
and the hardware, compression can also result in an increase in read
and write performance.
See https://pagure.io/fedora-btrfs/project/issue/5 for details. This
was originally scoped as an optimization for
https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora
33.
== Benefit to Fedora ==
Better disk space usage, reduction of write amplification, which in
turn helps increase lifespan and performance on SSDs and other
flash-based media. It can also increase read and write performance.
== Scope ==
* Proposal owners:
** Update anaconda to perform the installation using <code>mount -o
compress=zstd:1</code>
** Set the proper option in fstab (alternatively: set the XATTR)
** Update disk image build tools to enable compression:
*** lorax
*** appliance-tools
*** osbuild
*** imagefactory
** [optional] Add support for
[https://github.com/kdave/btrfs-progs/issues/328 setting compression
level when defragmenting]
** [optional] Add support for
[https://github.com/kdave/btrfs-progs/issues/329 setting compression
level using `btrfs property`]
* Other developers:
** anaconda: review PRs as needed
* Release engineering: https://pagure.io/releng/issue/9920
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
This Change only applies to newly installed systems. Existing systems
on upgrade will be unaffected, but can be converted manually with
<code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab`
and remounting.
== How to test ==
Existing systems can be converted to use compression manually with
<code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab`
and remounting.
== User experience ==
Compression will result in file sizes (e.g. as reported by du) not
matching the actual space occupied on disk. The
[https://src.fedoraproject.org/rpms/compsize compsize] utility can be
used to examine the compression type, effective compression ration and
actual size.
== Dependencies ==
Anaconda will need to be updated to perform the installation using
<code>mount -o compress=zstd:1</code>
== Contingency plan ==
* Contingency mechanism: will not include PR patches if not merged
upstream and will not enable
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
https://btrfs.wiki.kernel.org/index.php/Compression
== Release Notes ==
Transparent compression of the filesystem using zstd is now enabled by
default. Use the compsize utility to find out the actual size on disk
of a given file.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis