From Fedora Project Wiki
m (Update target release)
Line 43: Line 43:


== Current status ==
== Current status ==
* Targeted release: [[Releases/32 | Fedora 32 ]]  
* Targeted release: [[Releases/33 | Fedora 33 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  

Revision as of 12:01, 10 July 2020


Reduce installation media size by improving the compression ratio of SquashFS filesystem

Summary

Improve compression ratio of SquashFS filesystem on the installation media.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-07-10
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is compressed with default block size of mksquashfs. The default block size is 128k. Additionaly, lorax sets BCJ filter depending on the architecture. Those parameters can be adjusted which will lead to a better compression ratio and/or reduction of the CPU usage at build time.

Comparison of different SquashFS compression options and their impact on the time required to generate the SquashFS filesystem

This is simple to achieve. Recently, Lorax has gotten support for adjusting the compression options for mksquashfs via the configuration file. The file should be altered as following:

[compression]
bcj = no
args = -b 1M -Xdict-size 1M -no-recovery

Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively; bcj -- branch-call-jump filter.

Based on the results above, I'd suggest selecting the following optimal configuration: XZ algorithm, with block size of 1MiB and without BCJ filter (plain xz -b 1M, without -Xbcj x86). On the right, you can see the impact of the compression algorithms on installation time.

Different compression options and their impact on the installation time

As can be seen from the picture on the right hand side, selecting 'plain xz -b 1M configuration' has minimal impact on the installation time and CPU usage during the installation. The compression will result in +6.51% or, in real terms, +24.94s additional installation time, compared to the savings of 142 MiB on the installation media, refer to the documentation section to download the ISO images. This increase in installation time will be compensated by the change in the installer: https://github.com/rhinstaller/anaconda/pull/2292 I noticed, that even with maximum compression, CPU is not fully utilized during installation.

Alternative compression algorithms and the resulting filesystem size

Benefit to Fedora

  • Reduction of the installation media size and the cost of storing and distributing Fedora.
  • Reduction of the CPU usage at build time. Depending on which compression parameters chosen.

Scope

  • Proposal owners:

The build environment should have support for adjusting the Lorax configuration file and -squashfs-only parameter. Lorax is a program that produces the LiveOS/squashfs.img file on the installation media.

One of the ways to enable such customization is to introduce support in Pungi to pass -c option to Lorax.

  • Other developers:

The pungi utility should support passing the custom configuration file location to the Lorax utility. This option should apply during buildInstall phase of pungi.

  • Release engineering: [1]
  • Policies and guidelines: Not required.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change comes at a cost of higher memory usage during the installation. Based on my personal estimations, this should not be the issue. Since the decompression should require up to 1MiB per thread. At the moment, the decompression of SquashFS is single-threaded.

N/A (not a System Wide Change)

How To Test

mkdir -p /mnt/new /mnt/old
sudo mount -o loop,ro FedoraInstallationOld.iso
sudo mount -o loop,ro FedoraInstallationNew.iso
ls -l /mnt/{new,old}/LiveOS/squashfs.img

And then calculate the size difference.

User Experience

  • Decreasing the installation image size will reduce cost of mirroring and storing Fedora installation images.
  • Decreasing the installation image size will reduce the download time.
  • Increasing the block size on the current configuration with EXT4 file system, should increase latency while accessing the EXT4 filesystem. The exact impact is to be evaluated.
  • The impact of latency will be reduced, if the plain SquashFS option is be choosen.

Dependencies

Pungi, a utility that builds the compose, should include new functionality mentioned above. Alternatively, the /etc/lorax/lorax.conf should be altered in the environment where Lorax is running.

Contingency Plan

N/A

Documentation

https://pagure.io/releng/issue/9127.
mksquashfs(1)
lorax(1)
https://docs.pagure.org/pungi
Select ISOs can be downloaded at https://khomutsky.com/fedora-dvd/
Spreadsheet pictured above File:Comparison Table SquashFS.ods Multi-core decompression of SquashFS merge request

Release Notes